Phillip,
What you are suggesting is described in detail in Sun's Designing Enterprise
Applications with the Java 2 Platform, Enterprise Edition.
Sokol.
> -----Original Message-----
> From: Scott M. Stirling [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 9:34 PM
> To: JRun-Talk
> Subject: Re: Value-holder design methodology flaw?
>
> While this may or may not be the case for this particular question, I
> can tell you I talked to the architect of the Petstore app at LinuxWorld
> last Fall, and he wasn't too proud of it. It's since been completely
> re-architected and most of it re-written. The source should be released
> when J2EE 1.3 is final. So don't be surprised if you find glaring
> problems in the current Petstore app.
>
> Scott Stirling
> West Newton, MA
>
>
> On 08 Jan 2001 10:20:58 -0500, Rhodes, Phillip C. wrote:
> > In the Pet store, for every entity bean they define, there is a value
> object
> > holder. For example, there is an Order (the ejb) and the OrderModel.
> >
> > What I have a problem with is the immense amount of code duplicity. If
> my
> > Order object has 20 attributes, then I have to define the same 20
> attributes
> > in OrderModel (along with all the accessors).
> >
> > What I have done was to remove all the attributes from the OrderEJB and
> used
> > a class variable in OrderEJB of type OrderModel to hold all of its
> > attributes. OrderModel is the only place where the attributes are
> defined.
> > OrderEJB uses a private instance of OrderModel to store it's state.
> It's
> > getDetails() method (an ejb call) returns it's orderModel instance.
> >
> > Why wasn't this done initially?
> >
> > Phillip
>
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
