All - Business logic is appropriate in the entity bean layer and core J2EE patterns says so (even the new second edition). The question is not whether, but rather what logic belongs there. Two simple considerations to keep in mind:
1. Minimize relationships and dependencies 2. Minimize how many places a code snippet must reside (ideally never more than one place) Follow these simple rules and you cannot go wrong. You will find that rules can be classified. There are those related to how information is presented, those that drive branching logic (user workflow manifest as alternate flows in a use case; application workflow manifest in sequence diagrams), and calculations to name a few. Custom tags handle presentation rules, session beans the workflow and entity beans the calculations, in general. Also keep in mind that Java is object oriented and EJB is component-based. In a component-based design, a component can be made up of objects (as is the case with J2EE components) or structured code (typical of our Microsoft friends). Relationships between components are not hierarchical or composite (hence the composite entity pattern). A customer is not an order; a customer places orders but a customer doesn't have orders and certainly is not made up of orders. There is an association, but not coupled relationship (database key sharing aside, this is not a strong bond between components). An order has items - composition and so an item doesn't belong as a component separate from order. Order has items is a composite relationship since an order usually has little meaning without at least one item. Together, they form a small component for which there are probably other internal objects such as contact information, etc. Here's the thing: components are application workflow, asynchronous events or persistent entities. This is true in J2EE and .NET. Why the separation? Workflow and events change with time much faster than the underlying entities. Transaction processors first dealt with stateless components and could not handle persistence complexity. These two truths drove fat objects to split the data and behavior - away from encapsulation, to manage change and improve performance. Therefore, session beans have become known as business objects since they wrap (fa�ade to) entities. They also manage relationships between entities in pre-EJB 2.0. So think of object design as something to attain within your component, not between them. Then think of your components collaborating to get a job (use case) done. -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED] Behalf Of Joe Sam Shirah Sent: Friday: June 27, 2003 13.25 To: [EMAIL PROTECTED] Subject: Re: EJB design patterns ruin decent object design? Hi Janne, I have several issues with entity beans, but this is not one of them. If you check Chapter 4, under the section "Using Entity Beans", there is a subsection titled "Business Logic in Entity Beans". The entire section is worth reading, but I'll specifically quote: "In general, the entity bean should contain business logic that is self-contained to manage its data and its dependent objects' data." You are correctly concerned about objects maintaining methods and data, but careful analysis of objects and data is always required. In a very brief review of your example, it appears to me that there are, at least, User, Fines, and Book objects. There probably should be others to integrate them properly, but the point is that Books don't really care about Users and should only manage Book data. There might be some reference to a checked out status and either a reference to the User or a means to determine the User in a LibraryBook, but the User should handle its own methods and data. Best, Joe Sam Joe Sam Shirah - http://www.conceptgo.com conceptGO - Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International? http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 ----- Original Message ----- From: "Janne Mattila" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 27, 2003 3:31 AM Subject: EJB design patterns ruin decent object design? > 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". =========================================================================== 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".
