<snip>
>> I'm just looking at the latest petstore (1.1.2) and seeing that they use
the
>> structure of a separate model object within each entity bean to hold the
>> persistent attributes. They provide a method getDetails() which will
return
>> this object to a client.
>
>We do something similar and still have been able to keep the client code
>uncoupled from the data structures. We accomplish this in two ways. One is
to
>not send the entity bean's detail data object directly to the presentation
>layer. Instead, have the session bean facade handle repackaging the data in
a
>task (use case) appropriate data structure.
</snip>
Victor, you have clearly implemented a Facade and decoupled your client tier
from the business logic and data tiers in the process.
Sorry for the imprecision in terms of the word client. I meant eventual
client, for example a servlet/JSP in the web tier or a thick client Swing
App.
In the petstore 1.1.2 they use the AccountModel class within their Account
entity bean to hold the state and they also send it out to the webtier.
After closer inspection they appear to not use Facade at all. They use
something they call MVC where the client (object within webtier) asks the
controller (session bean) for the entity bean and then the client
interrogates the entity bean for it's contents - the AccountModel object for
example.
So they are still strongly coupled client tier to data tier.
What is the story with the pet store application people? Do they read the
Java Center patterns at all? I am a bit confused about the Sun vision for
building J2EE applications.
Comments?
Cheers
Jay
===========================================================================
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".
