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? [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? Methods are separated from the data? Business logic which is clearly associated with a given object ends up scattered through different session beans? Also, since CMP persistence is handled by the container, what is left in the entity beans if the business logic is also removed? =========================================================================== 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".
