Hi, thanks to all for the quite informative comments!
>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. By the way, the separation of presentation - workflow - "calculation" logic was quite, logical (no pun intended) and I agree. So if I understand correcly the detail about order-items relationship you say that order should be an entity bean but but item should not be. Now this is something that I still find a bit hard to swallow. Since EJB 2.x offers the means to model all your components with CMP so that you don't have to worry about persistence too much, why not use that for all objects? And would not using different persistence mechanisms for order and items complicate the design, where some components are persisted using CMP and some with another means? (I am not sure HOW the items would be persisted in that case - please could you explain). I recently stumbled across an interview on the Serverside, where this Floyd dude talked about EJB design with EJB 2.x. For me it was completely what I wanted to hear: http://www.theserverside.com/events/videos/FloydPatterns/dsl/interview.html He seems to suggesting that with the local interfaces the performance is improved so that coarse grained entity bean pattern is no longer needed and you can model your entire domain model with CMP entity beans. Now this is a design which would be at least consistent and you would not have to ponder over which objects should be a component and which not. Of course, there is still the overhead of an object being a component if it needed not to be - packaging, xml files etc. But still, along with the option of not having entity beans at all and using DAO s instead, this seems a more practical approach than having some entity beans and some other objects. (Maybe this is because I do not understand how you can combine CMP entity beans and dependent objects implemented with some other technology) =========================================================================== 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".
