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
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
