Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Where should business method be placed anyway  RSS feed

 
Leandro Melo
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
this is very controversy where i work, because there are 2 major opinions on this topic.

I'd like to hear others opinions about where should the business logic be placed. First, i'm gonna expose my opinion and Second, i'm going to expose some other guy opinion, so the ranchers can tell wich one they think is better.

Opinion 1 - If a business login belons/affects only one CMP (consequently only the rows of the CMP mapped table), insert this business login inside this CMP (an example would be "fillStock(30)"). But if the business login affects 2 or more CMPs, place this business logic inside a Session Bean between the Fa�ade and CMPs(an example would be transferMoneyFromThisAccountToThatAccount(1, R$30, 2)"). Naturally, for accessing this 2 kind of methods there will be a Session Fa�ade.


Opinion 2 - Always place the business logic inside a CMP, when this logic affects other CMPs, choose the one responsible for the login and place the business methods there. The same way, this logic will be accessed through a Fa�ade.


Well, I'd be very gratefull if people discuss this 2 points of view and tell me (with arguments or an example) why anyone of them is better.

Thanks and Regards,
ltcmelo
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36406
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I prefer another option:

Option 3:
Always put the busingess logic in a session bean.

I find it easier to test the logic that way. Also, it is better separated in case the logic uses a different CMP in the future. I keep all logic out of the CMP and just use them for pure data manipulation (and retrieving the whole bean as a value object.)
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Jeanne.

I'd only use entity bean (EB) as a pure representation of an entity (eg, record in db). In this case, EB would only have accessor methods (to modify column values in the record an entity bean is associated with) and all other business methods would be located in the appropriate SB.

 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I'd suggest option (4) -- Never put business logic in either a CMP or a session bean, but in a Plain Old Java Object (POJO) that sits between the session facade and the CMP. The reasons why are detailed in this article.

Kyle
[ July 11, 2004: Message edited by: Kyle Brown ]
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36406
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with option 4. We actually do this. Our code generation creates "strategy" classes that are called by the session bean. I think of these strategy classes as the work for the session facade even though they aren't in the bean. That's where option 3 came from.

Leandro, the developer's logic makes perfect sense for regular objects. What does he propose you do if the data persistence layer changes? Also, it's easier to test the code if you separate it into a different class than the entity bean.
 
Leandro Melo
Ranch Hand
Posts: 401
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeanne,
then it seems to me that placing business logic inside POJOs or inside the persistent objects can be thought of a trade off between pure OO design X more scalable, abstract, layered and robust application.
Am i correct?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
CMP Entity Beans will necessarily map fairly closely to database tables. This is probably not the best way to divide responsibilities between units of code. I like facades to present large grained APIs to clients, POJO business objects to provide ideal partitioning of business logic and CMPs to handle the unavoidable evil of relational storage. Well, actually I don't like CMPs much at all, but you get the idea.
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36406
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Leandro,
You get the EJB benefits by having your POJO called by the session bean. That way your application is still scalable, robust, etc and still is easy to maintain.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!