Hi, I agree with Mattias that when an entity bean has been developped, he should not be touched again to create new value objects. The developers of the business logic should come, see the entity and create new VO for their own uses. But I also agree with Dmitri that, to summarise, "wtf", it is so quick and simple using xdoclet. The best would be that the info needed to build a new VO, even if linked to the Entity Bean class (he, it comes from the persistent fields), would not be maintain *in* the entity bean but *somewhere else*. I guess this is what .net attributes address. I could use a xdoclet task to write a XML file that describe the entity (the list of its persistent field to keep it simple). Then I could use another tool that present this XML to the Entity *user* (one of the 20 developers that use *my* entity bean) and this tool will create the VO Factory, and the VO itself. And maybe I am simply redoing the J2EE "DD" in anolther way here :( IMHO this is where xdoclet shows its limit, ... and where MiddleGen or UML2EJB come to the rescue. The idea of accessing the entity bean itself everywhere using local interfaces is also an option. But I think that even if VO is painful, a similar concept is sometimes needed : to reduce the vision of a complete entity to a part of it to the "users" of the entity. So the problem of having to handle *N* views of *1* entity exists. The difference of responsability of maintaing the entity (container), creating the entity (the entity developer) and the user of the entity (this business logic or that business logic), also exists. And mixing the two with xoclet alone will never (a bit of provocation here) be possible. Vincent.
Dmitri Colebatch wrote: > 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 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
