Hi Chris,

no, I did not get *any* feedback - I ain't got *no* feedback. :-)

Cheers...
Matthias

> -----Original Message-----
> From: Shaw, Chris [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 01, 2002 2:10 PM
> To: 'Matthias Bohlen'
> Subject: RE: [Xdoclet-user] Value objects in entity beans considered
> deprecated
> 
> 
> did you get *any* feedback on this from the XDoclet group? (I 
> don't remember
> seeing any)
> 
> Chris 
> -=-=-
> 
> PS - Paul is still trying to get the Rose model to work with 
> UML2EJB but is
> trying to overcome some problems (perhaps due to the plugin? 
> we are using
> Unisys plugin 1.3.4). He/we will update you when we have some 
> news (positive
> or negative)
> 
> -----Original Message-----
> From: Matthias Bohlen [mailto:[EMAIL PROTECTED]]
> Sent: Friday 27 September 2002 15:01
> To: [EMAIL PROTECTED]
> Subject: [Xdoclet-user] Value objects in entity beans considered
> deprecated
> 
> 
> Hi,
> 
> I just had an interesting discussion on the uml2ejb-user 
> mailing list and
> thought it might be interesting what the XDoclet people think 
> about this
> point.
> 
> Opinions or ideas?
> Matthias
> 
> ----
> 
> Matthias Bohlen
> Consulting that helps project teams to succeed...
> 
> Web:
> http://www.mbohlen.de/
> 
> Snail:
> Luise-Albertz-Str. 25
> D-53340 Meckenheim
> Germany
> 
> Phone: +49 (170) 772 8545
> Fax: +49 (2225) / 945189
> 
> -----Original Message-----
> From: Matthias Bohlen [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 27, 2002 1:17 PM
> To: '[EMAIL PROTECTED]'
> Subject: Value objects in entity beans considered deprecated
> 
> 
> Hi, Chris and Stefan,
> 
> ...
> 
> Constructing value objects inside an entity bean is a 
> practice from EJB 1.1
> and is now considered deprecated since local interfaces exist in 2.0.
> 
> Why this?
> 
> The practice introduced maintenance problems in more than one 
> EJB project.
> This came because value objects are specific for the use case that the
> client executes. Different use cases require different 
> subsets of the entity
> bean's data. After a few months in the project, members of 
> several client
> teams will rush the office of the poor entity bean developer 
> and ask him to
> introduce again(!) a new kind of VO every three weeks or so. 
> (I exaggerate a
> little to make the point :-)). The quality of that entity 
> bean will decay
> quickly.
> 
> Now, what's the remedy?
> 
> Do not generate VOs in the entity bean. The right point for 
> VO generation is
> the session facade of the component that executes on behalf 
> of the client to
> support its workflow. Create a factory for VOs and get the 
> data from the
> entity bean via its local interface.
> 
> The effect?
> 
> Reuse of the entity bean will be easier, even in different 
> projects. Each
> project writes its own value object factories (for the same 
> entity beans) to
> support its own use cases. The original entity bean developer 
> may turn to
> the next task in line.
> 
> ---
> 
> SWIM? (see what I mean?) :-)
> 
> Matthias
> 
> P.S.: The code for VO generation in the UML2EJB sample entity 
> bean template
> is therefore questionable, too!
> 



-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user

Reply via email to