I have a question which follows along similar reasoning to the coarse-grained / fine-grained discussion below. To promote reuse of an EJB application you use CMP (either different EJB server or the same EJB server but different databases), this way the container (theoretically) optimizes the database calls for you. By using an EJB as a coarse-grained object you then have 2 options for the fine grain object: 1. define the fine-grained object to be stored as a database BLOB from the EJB - this keeps the persistance in the EJB. My question is when developing reporting applications against the EJB's, it would seem that you then need to call the EJB across the wire and instanciate the fine-grained objects from the BLOB before you can determine whether that information is required in the report - quiet an undertaking if this is a commerce site with hundreds of thousands of products and order that you might want to report against. 2. program the persistance into the fine-grain object - this method would allow you to map each attribute to a database row for reporting, but then you either have a BMP system or a CMP/BMP hybrid - neither which is optimal if you are developing EJB's to be components to be deployed in various containers (optimizing SQL, transactional integrity across clustered servers, etc.) Is one better than the other or is this just one of the many trade-offs required in application development? /Ian -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Jeffrey Sanchez Sent: Wednesday, July 19, 2000 3:32 PM To: [EMAIL PROTECTED] Subject: Re: Dumb Entities: Should Entity Beans Have (no) Behavior? 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". =========================================================================== 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".
