Hi,
I've been reading some J2EE books, most importantly "core J2EE patterns", and have been getting increasingly confused and also somewhat irritated by some EJB design issues. Core J2EE patterns seems to support the view of not having business logic in entity beans. Amongst others, refactorings "move business logic to session" and "wrap entities with session" suggest this.
This way, business logic related to use cases would be in different methods in session beans, and entity beans role would be left as dumb persistence mappers. To me this sounds rather unintuitive....isn't the point of object oriented design to have the data and the related functions (=business logic) in the same object?
I believe you're referring to encapsulation. Encapsulation can be as simple as accessors and mutators for attributes. The concept of "business logic" doesn't enter into the basic concepts of OO design.
The worst part of most patterns I've seen is the applicability and consequencs sections. Basically you always need to ask is this pattern appropriate to my use case. You'll find that it isn't in many cases or it needs modification before it is a good match.
For this particular pattern I find that putting basic validation and simple business logic (e.g. Is this user a senior citizen) in the entity bean. More complex business logic that involves multiple domain objects is best kept in session beans. And everything else ends up where is seems appropriate which is a just a judgement call.
[1] For example, a case of some library application where we have a concept of User and associated methods
User.loanBook(Book book); User.payFines(int dollars);
This is how I would probably associate the methods (of course loanBook() could be also associated with the Book object, but that's not relevant). But if the object design is done by the suggestions in the book, we have the business logic methods in either one or several session beans [2]:
BookLoanSessionBean.loanBookForUser(int userID, int bookID); PayFinesSessionBean.payFinesForUser(int userID, int dollars);
Again, both methods could could be in the same session bean but I think that's not relevant. Doesn't that approach sound rather more like functional programming than object oriented?
In this simple case I would agree. I wonder why you're using a stateless session bean. Why not use a statefull sesson bean like this:
UserCheckout.create(UserId userId); UserCheckout.loanBook(BookId bookid); UserCheckout.getOverdueAmt(); UserCheckout.payFines(double amt);
Is some or all this likely to happen in the same interaction with the user? You're likely to need more state than just the userid for most of this anyway. For instance loanBook might have a validation that the borrower cannot have more than 5 books on loan at any one time. And overdue is likely to need the same list of extant books.
Methods are separated from the data? Business logic which is clearly associated with a given object ends up scattered through different session beans?
Is the logic really intimately tied to the user? What if the library charges different fines for different kinds of books or other media. Is that logic tied to the user or the media? How about the case where the fine depends on both the user and media. Where do you put the logic then?
Also, since CMP persistence is handled by the container, what is left in the entity beans if the business logic is also removed?
Plenty. Of course the container is doing the work for you. Remember you access the entity bean thru an interface. There may be lots of code behind that interface for transactions, security, persistance, etc.... Just because you aren't writting it doesn't mean it doesn't exist.
--Victor
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
