James,
As you say, persistence of your data objects are trivial in the case of a
native Java persistence mechanism. Although most CMP implementations will
struggle with this arrangement, a good BMP oriented OR mapping tool would
work well.
<vendor>
We just happen to have such a beasty in the integration of Cocobase with
GemStone/J.
</vendor>
However, I think we are missing some important patterns here. Your design
assumes a bean maps to one "row" of data. We believe this is the wrong level
of granularity for a component. This poor pattern has been promoted by early
CMP implementations IMHO. Rather we believe a bean should equate to a graph
of related sub-objects (or dependent objects as they are lightly referenced
in the spec).
A side effect of this consideration is that we need more than getData() and
setData() methods on the bean. Depending on the client use case, various
different views of the bean and it's sub objects need to be passed to/from
the client. This is why we advocate the use of a session bean facade for the
client's interface. As to whether the client should see graphs of data
objects or nested hashmaps, we are leaning toward graphs of data (or view or
descriptor) objects. This provides for some logic to be imbedded in the view
objects should light weight behavior be required in them (e.g. an "edit
check" that runs in the client VM).
I have probably introduced more issues than I have solved hear, but I don't
by the idea of a silver bullet design patterns that is trivializing the more
difficult issues.
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: James Cook [SMTP:[EMAIL PROTECTED]]
> 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".
