There's only so many ways to boil water...
There is a useful mechanism (I shudder to use the term pattern) used in Model
View Controller GUI's that makes sense here.
It is commonly the case that you have a User Interface on one side, and a
domain model on the other side. For the domain, let's imagine the mythical
Person object. Please don't critique the design, as it is a contrived example
to illustrate a point - I would not design code like this...
So, the Person object has several attributes, one of which is the home Address
of the Person. Further, the Address object is composed of a StreetAddress, a
State, a ZipCode and a Country. So, on the one hand, you have the team
developing the user interface which makes use of Persons in the various twisty
maze of screens all alike. On the other hand, you have the team developing the
persistence model, which includes the Person class and various attendant
substructure classes.
The problem comes when the persistence team changes the way the objects are
arranged, and the user interface team has to change their code in order to
compensate.
So, what I've seen happen over and over is that the groups re-invent the
concept of an Adapter, which insulates the user interface team from the changes
that the domain modeling/persistence team makes to the way the underlying data
model is organized. For example, the domain modeling team suddenly discovers
that a Person can have multiple addresses and they have to change the way
addresses are related to the Person. Now the getter and setter methods for the
home address on class Person don't make sense and there's a crisis in the town
hall.
The Adapter is just a class that represents the contract between the two
groups. On the one hand, the user interface team has an abstract specification
of what they can do to the domain. On the other hand, the domain
modeling/persistence team gets to implement this specification any way they
like. The actual interface of the Adapter is a negotiated interface which will
evolve slowly over time, insulating the user interface from the wacky world of
the domain.
A lot of people seem to think that it's the job of the domain model to open up
their shorts to the user interface with getter and setter methods - the
java.bean model of the universe.
In my opinion, it's the job of the Adapter to carefully insulate the two sides
of the coin.
So what does this have to do with anything?
Consider the Adapter to be a Session bean. Whether the domain is implemented
with Entity beans is immaterial and quite simply, not something the client of
the interface should wonder about.
There's the law of Demeter which really provides a good heuristic for deciding
whether you should be killed for using getter and setter methods on domain
objects. "Only talk to your immediate friends" is the motto. To summarize
it's application here, if you are effectively doing:
someObject.getAddress().getState().getGovenor().getPoliticalParty().annualGraft
();
you are way too knowledgeable about how things are constructed under the
covers. The consequence is that the code that is doing this is extremely
sensitive to changes in objects 3 or four levels of indirection away from the
current method. This means that when something changes under the hood, the
code breaks, or acts unexpectedly.
The use of an Adapter, in the case of a user interface, or a Session bean, in
the case of a "client"/server application, keeps your code honest and it's
fingers out of places it shouldn't be.
Clearly, there's a lot of reasons to violate the law of Demeter, but it's a
heuristic, not something to follow religiously.
The useful thing is that the Adapter or Session bean, provides a useful
encapsulation interface which two subsystems can agree on, and insulate
themselves from each other. An interface that changes slowly compared to the
underlying domain model. If you have a zillion entity beans that your client
needs to manipulate to get things done, then imho, the client knows way too
much about what's going on, and there'll be a lot of problems maintaining the
client code, and getting it to perform efficiently (two symptoms that go hand
in hand).
From: Tom Jordan <[EMAIL PROTECTED]>
> Hi,
>
> I am new to ejb and have a couple of questions about using Entity beans. I
> have read the archives with some saying session beans should always wrap
> entity beans and others saying that its okay to directly use entity beans.
>
> I just wrote my first entity bean called Product using CMP and a test class
> to make sure it does what its suppose to and it does except the performance
> is terrible. Using a sql profiler I can tell that for every getXXX() method
> that is called, there is a separate database call that is reselect all the
> fields in the bean. Is this suppose to happen and if so how can I control
> this behavior so that calling 5 getMethods does not create 5 database hits.
> I am using TX_Required as the default for the bean.
>
> Another question and I think that it may be related to the 1st is the notion
> wrapping entity beans with sessions. Surely its is not suggested that all
> the get and set methods of an entity be replicated on the session. An while
> it may be necessary to use session beans to control the interaction between
> several beans, there are often situations where you need to do a series of
> gets on a bean to show the user. So how do we achieve this.
>
> I have reviewed the sample at
> http://www.execpc.com/~gopalan/java/session.html notice that he provides a
> method like getProduct() which would return a reference to the product
> interface (which is really an entity bean).
> In this situation would the object be passed by value or would it be a
> remote reference to an entity bean? would you still be able to do get an
> sets on this object and use it like an entity bean?
>
> Thanks in advance for your help and appolgize for the newbie nature of the
> questions.
> Tom
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.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".
