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.
This mailing list does not allow me to simply reply,
so I have to alter the original text here..
> 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".
