Matthias, > no, I did not get *any* feedback - I ain't got *no* feedback. :-)
[snip] > > 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? I'm probably not really the developer who ought to be commenting, but seeing as you're trying to invite feedback (o: I'll offer my thoughts. Firstly, I dont see why you wouldn't have the entity bean generate value objects... there's no _real_ difference between the session bean doing it and the entity bean doing it... but much of a muchness really (apart from that you may not want to expose all your accessor methods through the interface... Secondly, the problem of having various combinations of fields in the entity bean used in value objects is (I believe) fixed by the newer XDoclet value objects (as opposed to the originial data objects). Have you looked at the functionality provided there? It does almost exactly what you're looking for. cheers dim > > 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 ------------------------------------------------------- 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
