Dmitri, To add my feedback to this, the difference is really in the design. For small projects, it's fine to have the entity create the value objects. However, on medium to large projects, the design doesn't scale. This is because entities are supposed to be "domain objects" - not necessarily the view various clients want to see.
The idea of using a factory to generate value objects from the entities - and for the session bean - (who hands it off to the client) is because different clients want different views. The example I saw once was something like CarValue, ManufacturerValue, CompleteCarValue - where CompleteCarValue has getters and setters for properties from BOTH the CarBean and ManufacturerBean, a "flattened" out representation, so to speak. One might argue this and say that, "well then he should have a composition of value objects to match the cmr's then." The problem with this is what about the situation where a client needs data from both CarBean and ManufacturerBean, but doesn't want ALL the data? Maybe just a couple properties from each? To pull over a complete data graph would incur a bigger database read and more network traffic. Thus the need for more, finer grain value objects. However, to have knowledge of all those value objects in the entities would be a maintainance nightmare. A better design would be, again, to separate the domain data (the entities) from the logic of creating the value objects. Then, when project requirements dictate the need for another kind of value object, the change is kept to only the value object factory, and of course the new value object classes (inheritance or composition of the value objects would help here). Hope this made sense. I'm tired and hungry. ;) David -- 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
