John Smith wrote:
> We want to take advantage of entity beans and CMP, but also want to
> preserve
> our Domain Object Model to the greatest degree possible. It is sometimes
> suggested that an entity bean simply wraps the java object. The entity
> bean
> would then have two attributes of interest to us, the id, and a reference
> to
> the java object it represents.
>
> Thus we never really act on the entity bean, instead we get the domain
> object from it, act upon it and give it back to the entity bean to
> persist.
>
> We may also do "large" queries using sql in session beans, construct our
> domain objects from the results, and when done, pass them back to an
> entity
> bean for transactional updates.
>
> I would like to expose only the domain objects to the clients (session
> beans) probably using a facade of some sort with which our "findBy"
> requests
> would be delegated to the actual entity bean and the facade would return
> back to the client, domain objects.
>
>
> Questions:
>
> First - I'd like to know if anyone is using domain objects wrapped by
> entity
> beans, and if so, can you provide some insight into how you actually use
> the
> domain object from a client. Thoughts?
>
[Randy Stafford] Yes, we used domain objects wrapped by entity
beans in the open-source FoodSmart example J2EE application on the
"Developer's Guide" CD (freely available at http://www.gemstone.com). The
entity bean encapsulation is controlled by a start-up property, so the app
can run with either unencapsulated or encapsulated domain objects.
We made design decisions similar to the ones you have in mind.
Given domain objects, the only value entity beans provide is hooks for
synchronization with persistent storage (and there are other ways of
accomplishing that synchronization, that don't require the development and
runtime overhead of entity beans). Therefore we just let our entity beans
implement the same interface as the domain objects they wrap, and delegate
basically all behavior (including relationship navigation) to the wrapped
domain object.
Our entity beans do implement a method called getDomainObject(), and
that method is visible to clients of the entity beans (session beans and
other entity beans). The existence of this method exposes a bunch of issues
having to do with domain object distribution. If the domain object in
question participates in a large transitive closure, such that it is not
practically serializable, then you have to use other means of distributing
that domain object's state to remote clients (e.g., remote clients of your
session beans), and for performance and data integrity you probably also
need to use container-provided mechanisms to ensure that all EJBs involved
in a given system response run in the same VM and bypass the marshalling
required by the EJB spec even when all EJBs are in the same VM.
We do have one special-case usage of an entity bean for query search
results, corresponding to your point above (see also
http://www.c2.com/cgi/wiki?SearchResultAsEntityBean).
> Heres the first thing I come up with:
> Lets say we want to use a simple mutator on a domain object, for example,
> change a patients telephone number.
>
> 1 - the client makes a request for patient with last name of smith.
>
> 2 - If we were directly accessing entity beans from the client (session
> bean) we would have 3 remote references, update the one of interest and
> the
> container would insure it was persisted...
>
> In our case we get back three domain objects. We update the one of
> interest,
> and then what??? Sure, we submit it back for persistence. The facade will
> use the id to look up the entitybean, update it and persist it. But this
> seems like a lot of work!
>
[Randy Stafford] Sure, because you have to find (create) the entity
bean to update it (and you may have had to O/R map the three domain objects,
too, which could be expensive).
> Any other ideas?
>
[Randy Stafford] Yeah - don't use entity beans! I'm only being
partly facetious here. If you've already implemented a domain model, the
only thing entity beans are really buying you are the persistence hooks.
Depending on what other persistence logic you've already implemented, this
may or may not be valuable. The only other thing it buys you is some degree
of dubious-value spec compliance (but probably not container-independence,
due to the above-mentioned distribution issues).
And as you're seeing, doing the wrapping comes at some cost. Entity
beans don't handle significant domain complexity very well, due to issues
around representing inheritence, relationships, etc. Entity beans are also
all heavyweight remotable objects, and could saturate your server VMs and/or
cause a lot of cycles to be spent on activation/passivation in a high-scale
deployment. And this is to say nothing of the development effort required
to get it all working and maintain it.
<bias>Furthermore, you could save yourself the response time and
development effort contributions of O/R mapping if you persisted your domain
objects, whose value you obviously recognize, and whose development you've
invested in, in an object database ;-) </bias>
Best Regards,
Randy Stafford
Senior Architect
GemStone Professional Services
===========================================================================
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".
