Wei
At IBS we use an introspecting tool to generate xxxData classes that
reflect some data view (it makes use of the DatabaseMetaData++). These
classes work in conjunction with RDBMService, DBConnectionService and
TransactionService (in our EJB App Server). The are serializable and can
be returned to the client.
Tony
----
Wei Jiang wrote:
>
> 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.
>
> 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...
> > |
> >
> > +---------------+
> >
> > 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
> >
> >
> ===========================================================================
> > 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".
> >
> >
>
> __________________________________________________
> 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".
--
Tony Holderith | Interactive Business Solutions
[EMAIL PROTECTED] | NetCentric Solutions
http://www.interactivebusiness.com | Business Objects
voice: 310.414.6760, 805.389.4503 | fax: 310.414.6759
Don't connect to the Internet - be there. IBS
===========================================================================
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".
