Frank, Excellent point. There are several kinds of relationships to contend with in EJB, at least including: - Bean to bean, either aggregating or referencing. - Bean to dependent object. My opinion is that these are always aggregating relationships. If a bean needs to relate to a non-bean object, which is does not "own", then the dependent-object should probably be escalated to bean status. - Dependent object to bean. My opinion is that these are Never aggregating relationships. What am I missing? Examples: - Customer is a bean with dependent objects Address. Address is not referenced directly by other components, so it does not get promoted to bean. - Order is a bean with dependent objects OrderItems. OrderItems are only referenced by Order, so they are not beans. - Order relates to Customer, bean to bean. Customer owns Orders? (when customer is removed are all its Orders removed, probably so lest referential integrity be lost)... - OrderItems relate to bean Products. OrderItems do not own Products, but reference them. - InventoryBin relates to Products. Product is promoted to bean granularity because it is reference by more than one bean. And so it goes... One general question is should a bean merely wrap a domain object? Perhaps this is moot. It seems that whether we have bean wrap the first level domain object or not, we will have dependent objects that relate to other beans (e.g. OrderItem relates to Product, and OrderItem is not a bean but Product is). So in Jame's model perhaps the handling if relationships between SampleData and its related objects belongs in SampleData itself? Another question is whether "dumb" data objects (e.g. SampleData) belong in the component model at all. Dependent objects will have relationship semantics imbedded in them, either to other beans or child dependent objects, so they are not always "dumb" per se. Rather I think the "dumb" objects should be the view/descriptor/value holder... objects that are passed to/from a wrapping facade and its clients. I think it a mistake for us to try to force the client data view into the domain model. Divide and conquer! I would really appreciate constructive criticism of the ideas here. This is at least the second try to stoke the fires of debate on this. Regards, -Chris. ---------------------------------------------------------------------- Chris Raber, Director Professional Services, GemStone Systems Inc. 100 West Big Beaver, Suite 200, Troy, MI 48084 phone: (248)-680-6691, fax: (248)-680-6689, email: [EMAIL PROTECTED] web: http://www.gemstone.com/ ---------------------------------------------------------------------- > -----Original Message----- > From: Frank Sauer [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, July 21, 1999 9:32 PM > To: [EMAIL PROTECTED] > Subject: Re: fat getter/setters versus get/set with all data > > This looks good, but I have just one question: > > How does this model deal with relationships between beans? > Business logic in SampleBeanLogic might want to use some > other bean, but cannot directly reference the other bean and has > to go through the EJBObject wrapping the other bean. Idealy you > want to keep that out of the SampleBeanLogic class and have that > down in the SampleBean class. Also, if you use a mapping tool with > BMP, it will generate code for this. > > Should the SampleBeanHome have a create method taking a SampleData object > as an argument? Also, since SamplePK probably contains a subset of the > attributes of SampleData should SampleData extend SamplePK? > > Also, SampleBeanLogic should not directly implement the remote interface > (Sample), I like the idea of a SampleBusiness interface better. > > Frank Sauer > The Technical Resource Connection > mailto:[EMAIL PROTECTED] > > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook > Sent: Wednesday, July 21, 1999 4:54 PM > To: [EMAIL PROTECTED] > Subject: Re: fat getter/setters versus get/set with all data > > > I've thought of doing something like this, but backed off because I wasn't > sure how an EJBServer would support container managed persistence (CMP) > with > this approach. This topic is also an extension to the list-thread: > "generic > EJB thoughts" > > I finally came up with a hierarchy that seems to work well, although I > haven't tested it yet. Set your email viewer to non-proportional fonts and > the diagram below will make much more sense (It's hard to draw UML with > ASCII: > > +--------------+ implements +----------------+ > | EntityBean | <- - - - - - - - | BaseEntityBean | > +--------------+ +----------------+ > | ejbLoad(){} | > | ejbStore(){} | > +--------------+ +----------------+ > | Sample | <-------+ ^ > +--------------+ +------------+ | extends > | | > +--------------+ contains +--------------------------+ > | SampleData | <--------------- | SampleBeanLogic | > +--------------+ +--------------------------+ > | | SampleData data | > | implements +--------------------------+ > V | SampleData getData() | > +--------------+ | void setData(SampleData) | > | Serializable | +--------------------------+ > +--------------+ ^ > ^ | extends > | implements | > | +---------------+ > +--------------+ | SampleBean | > | SamplePK | +---------------+ > +--------------+ | ejbCreate(id) | > | ejbLoad() | > | etc... | > +---------------+ > > BaseEntityBean: responsible for a null implementation of EntityBean > interface. I actually have code in this class that can optionally printout > the time and method that is executing. That gives me some ability to view > when the container calls my ejbLoad, ejbStore, etc. methods. Also > setEntityContext and unsetEntityContext are implemented here. > > Sample: remote interface that declares the business methods available. > > SampleBeanLogic: only an implementation of the Remote interface goes in > here. This looks very good as there is no EJB specific code, only business > logic. There is also an attribute of type, SampleData which is a reference > to the object holding the business attributes. I implement the setData and > getData methods that pass the business attributes with a high level of > granularity. This satisfies the purpose that started these threads and > countless other threads on granularity. > > SampleData: a class that contains business attributes. Under certain > circumstances, when a Java client is involved, these classes could contain > field-level validation methods if the EJB server supports pass-by-value. > This simple validation will be very useful on the GUI client, and should > save much network traffic. > > SampleBean: for CMP beans, this is where the implementation of ejbCreate > will go, and that's about it. For BMP, all of the appropriate persistence > methods are implemented. This is very good separation since only database > code will exist here in most circumstances. > > SamplePK: hasn't changed. > > I would also advocate the business/remote separation pattern that has been > kicked around here. It creates yet another class, but for die-hard (aka > Glutteous Clenchimus) OOPists you can separate the Sample class into > SampleBusiness that is extended by Sample (which extends EJBObject). The > SampleBeanLogic then could implement SampleBusiness to ensure that the > appropriate classes were implemented at compile time. > > Could this be the holy grail of EJB design? Hardly, but it's worth > investigating. There have been other posts that mention a name-value pair > or > hashtable approach to passing data to and from the client. I suppose > name-value pairs as long as they were stored in an array to achieve > maximum > language/platform independence. XML would work as well. Personally, I > think > the SampleData class should perform better, require much less coding, and > in > the Java-Java world it should allow some validation to take place on the > client. > > The first problem that comes to mind with this approach involves CMP. With > the data attributes hidden behind an object reference (sampleData), how > could these Containers know which fields to persist? For those using > OODBMS, > I suppose you would persist the sampleData object...problem solved. For > the > other 80%(?) of us, I think we're stuck, until the Containers get just a > tiny fraction of a hair smarter and allow us to specify persistent > attributes as "sampleData.firstName". > > Secondly, I know some containers that can't even handle the > business/remote > separation pattern I mentioned earlier, let alone handle the separation of > the EntityBean implementation described above. > > I'm not sure if these shortcomings are our fault. I think we should be > able > to change our EJB component design to suit us, as long as it adheres to > the > spec. I think the container vendors should look upon this pattern as a > feature request. Some vendors may be able to support the pattern now. If > this is the case, I would look forward to hearing about it. If not, what > are > the challenges in implementing such a design? > > Now if we could convice Jim, Ian, the Valto folks or others to put up some > concrete diagrams describing the ever ellusive "EntityBean as Collections" > and the "Definitive Guide to What is a Dependent Object, and How Does One > Use Them?" all of life's mysteries would be solved. Then we could start > coding some applications for a change ;-) > > jim > > > ----- Original Message ----- > From: Terran Vigil <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 21, 1999 1:46 PM > Subject: fat getter/setters versus get/set with all data > > > > For performance reasons, I've been thinking about replacing my Entity > Bean > > getter and setter methods with fat .extractData() and .setData() > methods. > At > > the same time, I would create a serializable container class that would > wrap > > only the properties of the EntityBean. This would: > > > > - eliminate a plethora of getter and setter methods that clients can't > call > > anyway (I'm using the "SessionBean wraps EntityBean" model). > > > > - Prevent the EJB container from calling ejbStore() multiple times. > > Actually, I guess this is only a problem if the EntityBean is called > without > > a calling transaction. > > > > - Provide a data class for returning data to client since we aren't > going > to > > pass EJBObjects to client. > > > > What does everyone think? Anyone else doing this? > > > > Terran > > > > > ========================================================================== > = > > 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". =========================================================================== 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".
