Heiko,
In our FoodSmart example (http://www.JavaSuccess.com), we demonstrate a few
techniques to help with this problem.
First, agreeing with what you've said, we recommend that clients not access
domain objects directly, that they go through service objects. In EJB, this
means that EJB clients should not access entity beans directly, but rather
should go through session beans.
Second, we recommend that the service objects should encapsulate use cases
that the clients need to perform. These tasks are usually rather broad, not
fine-grained. So you shouldn't need to duplicate your entity beans getters
and setters in the session beans. You should tell the session bean what you
want done and let it do it.
Third, for manipulating the state of domain objects, we recommend two
patterns: Identity Holder and State Holder. Identity Holder is for
presenting a large list of domain objects to the user and allowing him to
select one. State Holder is for presenting the user a manageable amount of a
domain object's state and relationship graph.
In some use cases, the user will use the client to modify the state holder's
state, then pass it back to the server for processing within a short
transaction. The service object will use the changes in the state holder to
make corresponding changes to the original domain object. This enables all
of the changes to be made in one client/server round trip and doesn't
require that the domain object's getters and setters be exposed to the
client. (The state holder's getters and setters are exposed to the client,
but those are often different from the domain object's.)
This should get you going on the right track. Good luck.
Bobby
-----
Bobby Woolf
Senior Architect
GemStone Systems, a Brokat company
[EMAIL PROTECTED]
-----Original Message-----
From: Heiko Gottschling [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 02, 2001 07:51
To: [EMAIL PROTECTED]
Subject: [EJB-INT] Session beans as Facade to entity beans
Hi,
it seems to be commonly agreed that clients should not directly access
entity
beans, but use session beans as Facade (=design pattern). This works fine as
long as the entity beans are accessed via "bulk accessors" (aka value
objects). However, if the client needs to access the entities at a more
fine-grained level, this approach gets soon unhandy, since all accessor
methods of the entity bean have to be duplicated in the session bean.
Let's say, the entity bean has some methods:
public class MyEntity {
public Vector getA();
public Vector getB();
}
then, the session bean would have to look like this:
public class MySession {
public Vector getA(Object myEntityPrimaryKey) { ... }
public Vector getB(Object myEntityPrimaryKey) { ... }
}
This means, all accessor methods of the entity bean have to be duplicated in
the session bean, which I don't see much sense in (?).
My questions:
1) What's so bad about letting the clients access the entities directly?
2) Using the Facade pattern, is there any better way of providing
fine-grained access for the client?
thx
Heiko
P.S. In my case I can't use bulk accessors effectively, since the entities
contain some complex attributes like Vectors and tree-like structures, and I
would end up sucking the entire database into my bulk accessor object if I
tried to resolve all these attributes
===========================================================================
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".
