Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Business logic in the controller or another bean?  RSS feed

 
Vasilis Souvatzis
Ranch Hand
Posts: 94
1
Chrome Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I already know the answer but I'll ask anyway just to be sure.

I'm making a simple online store with JSF and pulling data from JavaDB. Right now, I populate the Lists that show the albums on the Store page. In the Shopping Cart bean, I have a method that calculates the total price, discount etc and shows them on the Cart page.

I guess the correct way to do it is to have these calculation methods (this is considered business logic if I'm not mistaken), in another session bean that just does that right? Calculate the prices and inject them in my controller. I shouldn't use the Lists that are for showing the album info but pull the albums from the DB and calculate the prices.

I fear I'm polluting my controller with discount prices and stuff that the user doesn't have to interact with anyway.
 
Dave Tolls
Ranch Hand
Posts: 2826
30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In most frameworks I've worked with (not used JSF, so take this with a pinch of salt) the controller handles routing, and not business logic.
So a request that comes in will be handed off to a suitable service in the service layer for handling all the nitty gritty and, once that's returned, it then passes whatever response back/forwards to wherever.

So in your case yes, I would have a service that's injected into the controller.
 
Vasilis Souvatzis
Ranch Hand
Posts: 94
1
Chrome Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alright then, I need to do some serious refactoring

It makes much sense now that I've thought more about it, because if I want to introduce an HTML-JS frontend I'll do what, re-calculate the prices on the client?

You're right, the controller must handle the routing and in my case the view's values. Nothing more.
 
K. Tsang
Bartender
Posts: 3648
16
Firefox Browser Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vasilis Souvatzis wrote:Alright then, I need to do some serious refactoring


Hold it there. You using JSF and the controller in JSF is that FacesServlet. You don't write a controller in your app.

The managed beans and POJO are actually models in JSF and the view is the view.

So having the business logic in your managed bean or in another class is what you really asking. Depending on how you set up those calculations are done (eg are they standard formulas?), putting them in another class will help.
 
Vasilis Souvatzis
Ranch Hand
Posts: 94
1
Chrome Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
K. Tsang you're right, I didn't use the correct terminology. I was referring to the managed beans as controllers. I've seen people refer to them as controllers, backing beans, managed beans...

Yes, the calculations are really simple (price - price * discount). Besides, I always think of other stuff to add later so having this functionality in other class will definitely help.
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apparently the NetBeans IDE creates JSF backing beans under the name "xxxController". It's a lie. As Tsang has said, JSF backing beans are not Controllers, they are Models and the actual JSF main Controller is the FacesServlet with sub-controllers as part of the tag implementations. You almost never write your own Controllers in JSF.

Actually, a backing/managed bean is  "dirty model", in that if often contains not only POJO data, but listeners (which are not Controller code, but may be used as assistants by Controllers) and Action processors, which are business logic hooks that technically aren't part of the MVC paradigm, but are essential to invoking business functions and navigating to new Views.

A purist would use a backing bean as pretty much a pure GUI data model (as opposed to the ORM persistence data models, for example) and offload business functions onto a pure business-tier class.

In real life, I generally don't do that, unless the business logic is very complex and/or something that I want to be able to re-use in a non-JSF context. Then again, a certain amount of my business logic is actually persistence business logic, and that sort of stuff I relegate to my persistence services tier, which operates above the DAO tier but within my database transactional context. It's where stuff that involves interaction between multiple database tables gets done.

Ideological purity is all very well, but if I can create one class instead of 2 and still be easily understood, I'd rather do that.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!