I've seen various articles recommend against both the 'dumb-entity' and the entity-bean-maps-to-row-in-db (i.e., not coarse-grained) approach. From the following BEA FAQ: http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_design.html#1029240 Entity EJBs should be coarse-grained You should not attempt to model every object in your system as an entity EJB. In particular, small subsets of data consisting of only a few bytes should never exist as entity EJBs, as the trade-off in network resources is unacceptable. For example, line items in an invoice or cells in a spreadsheet are too fine-grained and should not be accessed frequently over a network. In contrast, logical groupings of an invoice's entries, or a subset of cells in a spreadsheet may be modeled as an entity EJB, if additional business logic is required for the data. Entity EJBs should contain business logic Even coarse-grained objects may be inappropriate for modelling as an entity EJB if the data requires no additional business logic. For example, if the methods in your entity EJB work only to set or retrieve data values, it is more appropriate use JDBC calls in an RDBMS client or use a session EJB. Entity EJBs should encapsulate additional business logic for the modeled data. For example, a banking application that uses different business rules for "Platinum" and "Gold" customers might model all customer accounts as entity EJBs; the EJB methods can then apply the appropriate business logic when setting or retrieving data fields for a particular customer type. Optimize entity EJB data access ... Regards, Jeff Sanchez -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 19, 2000 2:55 PM To: [EMAIL PROTECTED] Subject: Dumb Entities: Should Entity Beans Have (no) Behavior? Dear All, In our design team, we are in the middle of an 'idelogical' discussion regarding the desired boundaries between entity and session beans in our product's architecture. According to one approach, entity beans should be simple, data-centric objects with no interesting behavior - analogous to rows in a database or C structs; all 'business logic' should reside in session beans. This 'dumb-entity' approach has 3 rules: (I) Entities have no behavior - all methods are accessors like get() and set() . (II) Entities are blind: they never use sessions or other entities. (III) All client interface is through sessions (do direct access to entities). The alternative approach allows entity beans to have business logic, and uses session beans for cross-entity operations or as an 'insulation layer' between the client and the entity beans. The dumb-entity approach has benefits and limitations: Benefits: ========= Stable persistence model: Changes in the business rules only affect the session beans, so the persistence model remains unchanged. This can be especially important if we use CMP. Fewer design decisions: The boundaries between entity beans and session beans are very clear: data goes into the entity beans, behavior into the session beans. Modularity: Since entities have no behavior they know nothing about each other. A change in an entity will only affect the relevant sessions ( and we usually only have a single session dealing with each entity). Context: If operations depend on client context information ( like client preferences), that information can be naturally accessible in a session bean. If entity beans have context-dependent, 'smart' operations, the context has to be passed to them via method arguments - which can be cumbersome. Limitations: ============ Performance: Operations can require a long 'Ping-Pong' between a session bean and the relevant entity bean(s). Since inter-bean communication is slower than intra-bean communication, the performance is degraded. We are afraid that the effect can be disastrous in the case of heavier operations on complex entities. Awkward Programming: Being used to OO, moving behavior to the session beans feels like going back to C. All behavior is expressed in terms of functions and everything must be passed as an argument. It is possible but difficult, and the resulting code can be hard to understand. It can also be very annoying. Conclusions: ============ My personal conclusion is that dumb-entities should be limited to cases where the entities are small and simple. In the case of complex, coarse-grained entities, the approach is difficult to implement (no OO) and may lead to unacceptable performance. In the simple cases, I am not sure whether the benefits outweigh the price. I'd really like to receive your opinion. Youval Bronicki Sungard Business Integration http://integration.sungard.com --------------------------------------------------- Get free personalized email at http://www.iname.com =========================================================================== 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".
