Be very careful about autogenerating valueobject/dataobject. Let me summarize a pattern I came up with:
- use one vo for one entity bean in ejb 1.1. xdoclet can generate everything for you. - in ejb2, 1-vo->1-ejb is not that useful, use local interfaces and start a UserTransaction in your base Action class in web tier. - Now if you are going to transfer some data for display/etc to a remote client (say a swing client) or you want to display some data in a web page and you don't want to do sophisticated traverses in ejbs or pass a huge graph of vo instances around then create a XyzListingRow class which is a simple flat class which only contains whatever the caller needs in the display. The attributes of this listing class are grabbed from a graph of entity objects. It's a one listing class -> n ejbs mapping. Sure you should code it yourself and code generation doesn't help here, though it's possible but at least xdoclet doesn't provide it yet. An alternative approach is going to the db directly and filling the listing class without loading ejbs. It's useful for sophisticated queries. I tend to use this strategy for search operations that return tens of listing objects, but in some cases it's even useful for single object editing scenarios too. So even if <valueobject/>/<dataobject/> subtasks are provided by xdoclet but they are only for a one to one mapping of vo<->ejbs. Don't let xdoclet dictate the architecture! Use code generation wisely :-) Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-user- > [EMAIL PROTECTED]] On Behalf Of Emerson Cargnin - SICREDI > Serviços > Sent: Thursday, July 25, 2002 12:31 AM > To: David Ward > Cc: Roland; [EMAIL PROTECTED]; jboss- > [EMAIL PROTECTED] > Subject: Re: [Xdoclet-user] CMR and value objects > > I think the worst problem when defining the approaches to vo's is what > how deep you go in the relations. I mean, if i need just the main data > of an entity or if I need the description of related entities in the > same request, you have to find the trade-off to get the middle point of > how many data will be sent for a request. > > We are creating a bank system that will run through satellite lines, > about a 1 second delay between central (JBoss) and bank offices (700 > with jboss/tomcat). That said, we had to create a way to avoid > transmiting data that would not be used, and not having to make a lot of > remote call to get all data to populate the view (struts too). > > We made a framework that works over a xml defining the data necessary > for each remote call, so that in the server the framework navigates > through the bean and generates an object of GenericVO class (basically a > HashMap), then the client creates a concrete vo collection using this > GenericVO. > > The business delegate will be used passing it a screen name and it > specific parameters. > > example of the view xml : > > <screenConfiguration> > <screen name="SCR001"> > <command name="getPraca"> > <fields> > <field name="oid" source="Oid"/> > <field name="uf" source="Municipio.Uf.Oid"/> > <field name="municipio" source="Municipio.Oid"/> > <field name="endereco" source="Endereco"/> > <field name="cepInicial" source="CepInicial"/> > <field name="cepFinal" source="CepFinal"/> > <field name="situacao" source="Situacao"/> > </fields> > </command> > </screen> > </screenConfiguration> > > in this example the method getPraca will bring some PracaEJB fields, and > some related fields, as Municipio.Uf.Oid that gets the MunicipioEJB > relation from PracEJB, UFEJB relation from MunicipioEJB and at last Oid > field from UFEJB. > > What you all think about this approach??? any sugestion, want more > details of the solution ?? > > obs: sorry sending for jboss-user list, but i thought this subject > coul'd be wanted there too. > > David Ward wrote: > > > I suggest using xdoclet from cvs, then use @value-object tags in your > > ejb on the persistent fields and relationship fields you want included. > > Then, in your build.xml, use the <valueobject/> and <entitycmp/> tags. > > The valueobject tag will generate valueobjects for you that also handle > > aggregations/compositions of other valueobjects, with helpful > > add,remove,update methods. Then, the entitycmp tag will create an > > abstract subclass of your ejb that has similar helpful methods to > > persist your valueobject data (including traversing relationships). Just > > make sure to make abstract methods with @ejb:interface-method on them in > > your ejb so you can make use of them from your session facade. > > > > Hope this helps, > > David > > > > -- > > > > Roland wrote: > > > >> Hello, > >> > >> Is there a best practice/pattern for creating value objects for > entities > >> with CMR fields/relationships?? > >> > >> I am migrating to CMP 2.0 and am having trouble deciding how to use > >> value objects. That is, previously when I used our own relationship > >> framework, we would have simple accessors for relationships. Now with > >> CMP 2.0 we have local objects (and collections of local objects) as > >> return types. > >> > >> What is the best practice for creating these value objects? Moreover, > >> we have a session façade which passes the vo to a business delegate up > >> to our controller layer (Struts actions). Isn't it bad form to touch > >> your model (local objects) from the controller layer? > >> > >> Don't know if this being asked in the wrong place or not, but I'd > >> appreciate any input out there. Examples are also welcome. > >> > >> Regards, > >> RC > > > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > > -- > Emerson Cargnin - MSA > SICREDI - Tel : 3358-4860 > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
