see below
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Wei Jiang
> Sent: Thursday, August 19, 1999 10:19 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Inheritance and EJB
>
>
> The key point of this design is that you have a
> standalone data object (SampleData).
>
> We all came from general Object Oriented Analysis in
> which every object is created equal. But now,
> EntityBean represants data in database, so it is
> a prisoner in a container. You want free it, separate
> it from EJB.
>
Actually, the design drawing I made treats the Data object as a delegate,
therefore it *is* separate from the EJB itself. In practice, I have yet to
make this work, mostly due (IMO) to Container restrictions.
I currently use the following hierarchy because it works...
BaseEntityBean implements EntityBean
- null implementation of ejbLoad, ejbStore, etc.
- context handling
- tuned update support
- UID generator
^
|
SampleBeanBusiness extends BaseEntityBean
- business attributes
- all business logic
^
|
SampleBean extends SampleBeanBusiness
- For BMP, all persistence methods implemented
- For CMP, no methods at all :)
I believe the disadvantage of this approach is that my business attributes
cannot be conveniently bundled up and serialized to my client. I would have
to create yet another object(s) to represent my attributes and send them
down. If I could delegate my "business attribute" class, I could simply
serialize it as is.
Chris R. and others have indicated the disadvantages of this approach as
being one "business object" does not fit all situations, especially when
varying views of the object are necessary. For example, a list box control
on the client may need very little of the business attributes, but sometimes
more than just the PK. Another example, client security may restrict certain
attributes. I see the need for these views, but 80% of the time in my code,
I want the business object as is.
I could even envision a Hash map of my business attributes in a
BusinessObject superclass, that can map attributes to security roles and
build a name=value struct on the fly. This may have some promise.
In a mixed-language, pure-CORBA environment, you don't want to serialize
Java classes. You want to stick with primitive types. This name=value struct
could prove useful in these situations. Might need to store the type in
there somewhere as well...
jim
> I do not oppose your idea. Just want to participate
> in this discussion.
>
> If the container is the only user of the database,
> EJB's idea is okay. But in the real world, database
> is shared, for example, legacy program shares database
> with EJB. What is going to happen if the legacy
> program deleted the data, while you still have a
> handle
> of an EntityBean which represents the data? In that
> case, a floating object would be better idea.
>
> I used Object database (PSE pro) for some time.
> First, I was not comfortable with it. I want to
> separate my data and my GUI. But, It does not allow
> me to do so. object database is the image of your
> java memory. So, I build
> a "separator", which transfers between database
> objects and java objects. It works.
>
> Now, I use EJB and meet simalar issues. This time,
> I do not intent to build that "separator". Just
> obey to its rules.
>
> I would like to know other people's idea.
>
> --- James Cook <[EMAIL PROTECTED]> wrote:
> > Since this topic is garnering some attention now, I
> > though I'd post a prior
> > message regarding the topic. I apologise for the
> > redundancy.
> >
> > Original Post
> > ==============
> > 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...
> > |
> >
> > +---------------+
> >
<snip>
>
> __________________________________________________
> Do You Yahoo!?
> Bid and sell for free at http://auctions.yahoo.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".
