Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-08 Thread fabio
Thank you Joseph,

I agree with you concerning the long term benefits of the DTO approach. But 
there are some concerns too:

   - how do you make the transtyping ? Dedidcated framework like Doze ? 
   Hand coded approach ? Direct building using HQL ?
   - In my experience (accounting apps) the ratio between simple CRUD 
   screens to core business screens is 3 to 1. It means most of the time the 
   DTO needed on the client side will be the exact mirrors of their entity 
   counterparts. But every time you will be adding a new field, you 'll have 
   to modify the entity, the DTO and your DTO building code/settings. So this 
   use case (direct mirror) should be handled in a special and most efficient 
   way.

Truely yours,

Le samedi 7 avril 2012 19:09:08 UTC+2, Joseph Lust a écrit :

 fabio,

 While mechanisms like *Objectify* exist to pass the same entity to the UI 
 from Hibernate, I have found that DTO objects are still the most robust 
 solution. Obviously you don't want to send the secret Hibernate goodness to 
 the UI, you don't want LazyLoading exceptions, and chances are the entity 
 has way more information than you need in the UI. Since we often have to 
 move a lot of information to the UI (i.e. 10K plus records) it makes sense 
 to use the Entity in the DAO layer and pack up the data into the DTO's in 
 the service layer in an efficient manner. Keep in mind too that if you pass 
 your entity bean to the UI, you're telling prying eyes a lot about your DB 
 design.

 Also, we usually use a DtoContainer object for many pages. For example, if 
 WidgetX needs 10 fooDTO's and 3 barDTO's, then you pack them up in a 
 WidgetXContainer. This is especially useful because if you decide later 
 that WidgetX needs 4 wombatDTO's, you whole RPC setup from interfaces, to 
 services, to async handlers don't need to be touched. You just add another 
 property to the container and then just put in and take out the new object.

 Others might push for a framework like Objectify, but my experience with 
 such frameworks is that you lose in the long term if you plan to do 
 anything beyond the purview of their limited use cases.

 Sincerely,
 Joseph


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/eQaaSkieNhkJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-08 Thread fabio
Thanks  Sanjiv,

After reading your post that seems to recommend SmartGWT EE is the solution 
to this problem, I must say that this solution seems very close to what 
RequestFactory implements.

Truely yours,

Le samedi 7 avril 2012 20:00:46 UTC+2, Sanjiv Jivan a écrit :

 Hi fabio,
 I've shared my thoughts on this subject here : 
 http://www.jroller.com/sjivan/entry/solving_the_dto_dilemma

 Sanjiv

 On Sat, Apr 7, 2012 at 7:44 AM, fabio njo...@gmail.com wrote:

 I'm just about to start a major web  app project (rewriting the main 
 product or a sofware vendor) .  In the past I've been a project manager or 
 a developer in some small GWT projects. I think GWT is a good choice for 
 business app with a lot of tabular  data and information. But still I have 
 some concerns.

- GWT-RPC was one of the reason, I chose GWT in the past because of 
the magic of using (almost) the same objects on the server and client 
sides. To cope with the serialization and HIbenrante Lazy loading issues, 
we 've been using 2 strategies :  
   - 1/ A modified version  of Dozer (powerful but needs tweaking) 
   used to transtype HIbernate objects into a dedicated DTO layer
   - 2/ Directly buidling dedicated objects for GWT (infact on this 
   project we even use the same genric structure for entities, a kind of 
   enhanced map of properties with an additional type and id 
 attributes. 
- Today there is a kind of fog around these questions: GILEAD is not 
maintained any more, the new RequestFactory API seems awkard to me 
(especially with all these loose conventions) 

 So in a nutshell what guys do you recommend for client / server 
 communication in GWT today ?


  

 -- 
 You received this message because you are subscribed to the Google Groups 
 Google Web Toolkit group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/google-web-toolkit/-/hsHStUExV5sJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to 
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/google-web-toolkit?hl=en.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/BzGSSCBzBssJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-08 Thread fabio
Hello Daniel

Let me be explain (maybe some of my assumptions are wrong, so don't 
hesitate to correct me :-) ):

   - The extra plumbing is pretty heavy, one extra interface for each 
   entity you want to pass
   - No compile-time checking between properties in the enity and in the 
   client interfaces (but maybe the GWT plugins in Eclipse emit some warnings 
   ?)
   - You cannot return from  the same call normal POJO objects and 
   RequestFcatory Serialized Ones 
   - It makes the whole RPC stacks in GWT feel unclear. Too many ways to 
   achieve the same goal. Ideally I would have a prefer a single way (the 
   legacy GWT-RPC) that coud have been customized through parameter 
   annotations to alter the way serialization occurs by default. I think the 
   GWT team has made great efforts to solve commonly encountered issues with 
   GWT-RPC but they have lost the magic and beauty of their initial design in 
   the process.



Le dimanche 8 avril 2012 06:55:22 UTC+2, Daniel Mauricio Patino León a 
écrit :

 RF awkward ? I dont think so, finally the rpc aproach with dto's and other 
 stuff are sent to the client side in some like JSON (GWT Serialization), 
 RequestFactory uses JSON to pass from server to the client and it just 
 works well. In my opinion (i did two projects with the DTO thing) the 
 RequestFactory its the best way to build Enterprise Applications with JPA 
  (Hibernate). I recommend to you read careful the documentation about the 
 RF.
 Just my opinion.

 El 7 de abril de 2012 17:20, Jeff Schnitzer j...@infohazard.orgescribió:

 Just to clarify:  Objectify isn't a serialization framework.  It's a
 persistence API - Hibernate for the GAE datastore makes me cringe
 but it gives you the right idea.  Using Objectify you still have to
 decide whether to use your entity domain objects or DTOs for the
 GWT-RPC boundaries.  I tend to use DTOs, although I'll use the entity
 objects themselves if they are simple enough.  They usually aren't.

 Jeff (creator of Objectify)

 On Sat, Apr 7, 2012 at 1:09 PM, Joseph Lust lifeofl...@gmail.com wrote:
  fabio,
 
  While mechanisms like Objectify exist to pass the same entity to the UI 
 from
  Hibernate, I have found that DTO objects are still the most robust 
 solution.
  Obviously you don't want to send the secret Hibernate goodness to the 
 UI,
  you don't want LazyLoading exceptions, and chances are the entity has 
 way
  more information than you need in the UI. Since we often have to move a 
 lot
  of information to the UI (i.e. 10K plus records) it makes sense to use 
 the
  Entity in the DAO layer and pack up the data into the DTO's in the 
 service
  layer in an efficient manner. Keep in mind too that if you pass your 
 entity
  bean to the UI, you're telling prying eyes a lot about your DB design.
 
  Also, we usually use a DtoContainer object for many pages. For example, 
 if
  WidgetX needs 10 fooDTO's and 3 barDTO's, then you pack them up in a
  WidgetXContainer. This is especially useful because if you decide later 
 that
  WidgetX needs 4 wombatDTO's, you whole RPC setup from interfaces, to
  services, to async handlers don't need to be touched. You just add 
 another
  property to the container and then just put in and take out the new 
 object.
 
  Others might push for a framework like Objectify, but my experience with
  such frameworks is that you lose in the long term if you plan to do 
 anything
  beyond the purview of their limited use cases.
 
  Sincerely,
  Joseph
 
  --
  You received this message because you are subscribed to the Google 
 Groups
  Google Web Toolkit group.
  To view this discussion on the web visit
  https://groups.google.com/d/msg/google-web-toolkit/-/odd9_XG1AHAJ.
 
  To post to this group, send email to 
 google-web-toolkit@googlegroups.com.
  To unsubscribe from this group, send email to
  google-web-toolkit+unsubscr...@googlegroups.com.
  For more options, visit this group at
  http://groups.google.com/group/google-web-toolkit?hl=en.

 --
 You received this message because you are subscribed to the Google Groups 
 Google Web Toolkit group.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to 
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/google-web-toolkit?hl=en.




 -- 
 ISC. Daniel Mauricio Patiño León.
 Liondev S.A. de C.V.




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/AAuVV59-66YJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-08 Thread Thomas Broyer
I'd recommend request factory. The issues with rpc are:
 * rpc strongly couples your client and server, so you face invocation 
exceptions every time you deploy a server side change. RF on the other hand is 
a protocol, not an RPC API.
 * generator bakes every subclass of your objects on the client. That means you 
have to be very careful with what types you use / are in the classpath when you 
compile. With RF you only have what you want, you're in complete control.
 * batch requests are baked into the RF protocol, you don't have emulate them 
with dto containers. Plus you can easily change your mind at any time, and 
also possibly batch things from independent components (loose coupling ftw)

Sure RF has a steeper learning curve but I believe you win in the long term.
I'd suggest you upgrade to 2.5 as soon as its released though: many fixes to RF 
are coming.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/3xj5_VbmPRUJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-08 Thread Jesse Hutton
Hi fabio,

RequestFactory is great if you have complex data structures (and lots
of them) to pass back and forth between the client and the server. It
does take more boilerplate to get simple things done, but once you
pass a certain threshold of complexity it pays off big, because it
will serialize your object graph for you (and give you complete
control about what is actually sent over the wire.)

RF also has support for request batching, reducing http request to the
server. Another benefit is that it integrates support for
BeanValidation. And it also works with the Editor framework, which
makes data binding on the client much less tedious.

A few comments inline:

On Sun, Apr 8, 2012 at 4:24 AM, fabio njo...@gmail.com wrote:
 Hello Daniel

 Let me be explain (maybe some of my assumptions are wrong, so don't hesitate
 to correct me :-) ):

 The extra plumbing is pretty heavy, one extra interface for each entity you
 want to pass
 No compile-time checking between properties in the enity and in the client
 interfaces (but maybe the GWT plugins in Eclipse emit some warnings ?)

Incorrect. RF will validate your proxy and request interfaces for you
at compile time. See
http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation

 You cannot return from  the same call normal POJO objects and
 RequestFcatory Serialized Ones

On the client side, all request factory serializable objects extend
BaseProxy and are simple interfaces. You can return pojos and entities
in a single request, but you have to have define a ValueProxy
interface for your pojos and EntityProxy for your entities.

 It makes the whole RPC stacks in GWT feel unclear. Too many ways to achieve
 the same goal. Ideally I would have a prefer a single way (the legacy
 GWT-RPC) that coud have been customized through parameter annotations to
 alter the way serialization occurs by default. I think the GWT team has made
 great efforts to solve commonly encountered issues with GWT-RPC but they
 have lost the magic and beauty of their initial design in the process.

RF is not meant to replace GWT-RPC, which I think is still better for
simpler use cases. But, for heavily data-oriented services, RF (in
conjunction with the Editor framework) wins.

Jesse

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-08 Thread Thomas Broyer
The extra interface is a false problem: how's it different from dtos? You can 
also have several interfaces for a single domain object, each one exposing 
different fields. 

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/NSirFBaFF3wJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-08 Thread fabio
OK I'm pretty convinced now, I will give RF a try !

Le dimanche 8 avril 2012 16:16:14 UTC+2, Thomas Broyer a écrit :

 I'd recommend request factory. The issues with rpc are:
  * rpc strongly couples your client and server, so you face invocation 
 exceptions every time you deploy a server side change. RF on the other hand 
 is a protocol, not an RPC API.
  * generator bakes every subclass of your objects on the client. That 
 means you have to be very careful with what types you use / are in the 
 classpath when you compile. With RF you only have what you want, you're in 
 complete control.
  * batch requests are baked into the RF protocol, you don't have emulate 
 them with dto containers. Plus you can easily change your mind at any 
 time, and also possibly batch things from independent components (loose 
 coupling ftw)

 Sure RF has a steeper learning curve but I believe you win in the long 
 term.
 I'd suggest you upgrade to 2.5 as soon as its released though: many fixes 
 to RF are coming.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/6-ybzy3gXnUJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-08 Thread Roy Yeung
I prefer gwt-rpc. Baiscally, the main issue you finally meet is how to 
reproduce the same object/domain model across gwt and server side. Using 
gwt-rpc, you can shared the code. 

Sent from my iPhone

On 7 Apr, 2012, at 7:44 PM, fabio njo...@gmail.com wrote:

 I'm just about to start a major web  app project (rewriting the main product 
 or a sofware vendor) .  In the past I've been a project manager or a 
 developer in some small GWT projects. I think GWT is a good choice for 
 business app with a lot of tabular  data and information. But still I have 
 some concerns.
 GWT-RPC was one of the reason, I chose GWT in the past because of the magic 
 of using (almost) the same objects on the server and client sides. To cope 
 with the serialization and HIbenrante Lazy loading issues, we 've been using 
 2 strategies : 
 1/ A modified version  of Dozer (powerful but needs tweaking) used to 
 transtype HIbernate objects into a dedicated DTO layer
 2/ Directly buidling dedicated objects for GWT (infact on this project we 
 even use the same genric structure for entities, a kind of enhanced map of 
 properties with an additional type and id attributes.
 Today there is a kind of fog around these questions: GILEAD is not maintained 
 any more, the new RequestFactory API seems awkard to me (especially with all 
 these loose conventions)
 So in a nutshell what guys do you recommend for client / server communication 
 in GWT today ?
 
 
  
 -- 
 You received this message because you are subscribed to the Google Groups 
 Google Web Toolkit group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/google-web-toolkit/-/hsHStUExV5sJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to 
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/google-web-toolkit?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-07 Thread fabio
I'm just about to start a major web  app project (rewriting the main 
product or a sofware vendor) .  In the past I've been a project manager or 
a developer in some small GWT projects. I think GWT is a good choice for 
business app with a lot of tabular  data and information. But still I have 
some concerns.

   - GWT-RPC was one of the reason, I chose GWT in the past because of the 
   magic of using (almost) the same objects on the server and client sides. To 
   cope with the serialization and HIbenrante Lazy loading issues, we 've been 
   using 2 strategies : 
  - 1/ A modified version  of Dozer (powerful but needs tweaking) used 
  to transtype HIbernate objects into a dedicated DTO layer
  - 2/ Directly buidling dedicated objects for GWT (infact on this 
  project we even use the same genric structure for entities, a kind of 
  enhanced map of properties with an additional type and id attributes.
   - Today there is a kind of fog around these questions: GILEAD is not 
   maintained any more, the new RequestFactory API seems awkard to me 
   (especially with all these loose conventions)

So in a nutshell what guys do you recommend for client / server 
communication in GWT today ?


 

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/hsHStUExV5sJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-07 Thread Joseph Lust
fabio,

While mechanisms like *Objectify* exist to pass the same entity to the UI 
from Hibernate, I have found that DTO objects are still the most robust 
solution. Obviously you don't want to send the secret Hibernate goodness to 
the UI, you don't want LazyLoading exceptions, and chances are the entity 
has way more information than you need in the UI. Since we often have to 
move a lot of information to the UI (i.e. 10K plus records) it makes sense 
to use the Entity in the DAO layer and pack up the data into the DTO's in 
the service layer in an efficient manner. Keep in mind too that if you pass 
your entity bean to the UI, you're telling prying eyes a lot about your DB 
design.

Also, we usually use a DtoContainer object for many pages. For example, if 
WidgetX needs 10 fooDTO's and 3 barDTO's, then you pack them up in a 
WidgetXContainer. This is especially useful because if you decide later 
that WidgetX needs 4 wombatDTO's, you whole RPC setup from interfaces, to 
services, to async handlers don't need to be touched. You just add another 
property to the container and then just put in and take out the new object.

Others might push for a framework like Objectify, but my experience with 
such frameworks is that you lose in the long term if you plan to do 
anything beyond the purview of their limited use cases.

Sincerely,
Joseph

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/odd9_XG1AHAJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-07 Thread Sanjiv Jivan
Hi fabio,
I've shared my thoughts on this subject here :
http://www.jroller.com/sjivan/entry/solving_the_dto_dilemma

Sanjiv

On Sat, Apr 7, 2012 at 7:44 AM, fabio njo...@gmail.com wrote:

 I'm just about to start a major web  app project (rewriting the main
 product or a sofware vendor) .  In the past I've been a project manager or
 a developer in some small GWT projects. I think GWT is a good choice for
 business app with a lot of tabular  data and information. But still I have
 some concerns.

- GWT-RPC was one of the reason, I chose GWT in the past because of
the magic of using (almost) the same objects on the server and client
sides. To cope with the serialization and HIbenrante Lazy loading issues,
we 've been using 2 strategies :
   - 1/ A modified version  of Dozer (powerful but needs tweaking)
   used to transtype HIbernate objects into a dedicated DTO layer
   - 2/ Directly buidling dedicated objects for GWT (infact on this
   project we even use the same genric structure for entities, a kind of
   enhanced map of properties with an additional type and id attributes.
- Today there is a kind of fog around these questions: GILEAD is not
maintained any more, the new RequestFactory API seems awkard to me
(especially with all these loose conventions)

 So in a nutshell what guys do you recommend for client / server
 communication in GWT today ?




 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/hsHStUExV5sJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-07 Thread Jeff Schnitzer
Just to clarify:  Objectify isn't a serialization framework.  It's a
persistence API - Hibernate for the GAE datastore makes me cringe
but it gives you the right idea.  Using Objectify you still have to
decide whether to use your entity domain objects or DTOs for the
GWT-RPC boundaries.  I tend to use DTOs, although I'll use the entity
objects themselves if they are simple enough.  They usually aren't.

Jeff (creator of Objectify)

On Sat, Apr 7, 2012 at 1:09 PM, Joseph Lust lifeofl...@gmail.com wrote:
 fabio,

 While mechanisms like Objectify exist to pass the same entity to the UI from
 Hibernate, I have found that DTO objects are still the most robust solution.
 Obviously you don't want to send the secret Hibernate goodness to the UI,
 you don't want LazyLoading exceptions, and chances are the entity has way
 more information than you need in the UI. Since we often have to move a lot
 of information to the UI (i.e. 10K plus records) it makes sense to use the
 Entity in the DAO layer and pack up the data into the DTO's in the service
 layer in an efficient manner. Keep in mind too that if you pass your entity
 bean to the UI, you're telling prying eyes a lot about your DB design.

 Also, we usually use a DtoContainer object for many pages. For example, if
 WidgetX needs 10 fooDTO's and 3 barDTO's, then you pack them up in a
 WidgetXContainer. This is especially useful because if you decide later that
 WidgetX needs 4 wombatDTO's, you whole RPC setup from interfaces, to
 services, to async handlers don't need to be touched. You just add another
 property to the container and then just put in and take out the new object.

 Others might push for a framework like Objectify, but my experience with
 such frameworks is that you lose in the long term if you plan to do anything
 beyond the purview of their limited use cases.

 Sincerely,
 Joseph

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/odd9_XG1AHAJ.

 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Client/Server communication. GWT-RPC ? GIlead ? Dozer ? RequestFactory ?

2012-04-07 Thread Daniel Mauricio Patino León
RF awkward ? I dont think so, finally the rpc aproach with dto's and other
stuff are sent to the client side in some like JSON (GWT Serialization),
RequestFactory uses JSON to pass from server to the client and it just
works well. In my opinion (i did two projects with the DTO thing) the
RequestFactory its the best way to build Enterprise Applications with JPA
 (Hibernate). I recommend to you read careful the documentation about the
RF.
Just my opinion.

El 7 de abril de 2012 17:20, Jeff Schnitzer j...@infohazard.org escribió:

 Just to clarify:  Objectify isn't a serialization framework.  It's a
 persistence API - Hibernate for the GAE datastore makes me cringe
 but it gives you the right idea.  Using Objectify you still have to
 decide whether to use your entity domain objects or DTOs for the
 GWT-RPC boundaries.  I tend to use DTOs, although I'll use the entity
 objects themselves if they are simple enough.  They usually aren't.

 Jeff (creator of Objectify)

 On Sat, Apr 7, 2012 at 1:09 PM, Joseph Lust lifeofl...@gmail.com wrote:
  fabio,
 
  While mechanisms like Objectify exist to pass the same entity to the UI
 from
  Hibernate, I have found that DTO objects are still the most robust
 solution.
  Obviously you don't want to send the secret Hibernate goodness to the UI,
  you don't want LazyLoading exceptions, and chances are the entity has way
  more information than you need in the UI. Since we often have to move a
 lot
  of information to the UI (i.e. 10K plus records) it makes sense to use
 the
  Entity in the DAO layer and pack up the data into the DTO's in the
 service
  layer in an efficient manner. Keep in mind too that if you pass your
 entity
  bean to the UI, you're telling prying eyes a lot about your DB design.
 
  Also, we usually use a DtoContainer object for many pages. For example,
 if
  WidgetX needs 10 fooDTO's and 3 barDTO's, then you pack them up in a
  WidgetXContainer. This is especially useful because if you decide later
 that
  WidgetX needs 4 wombatDTO's, you whole RPC setup from interfaces, to
  services, to async handlers don't need to be touched. You just add
 another
  property to the container and then just put in and take out the new
 object.
 
  Others might push for a framework like Objectify, but my experience with
  such frameworks is that you lose in the long term if you plan to do
 anything
  beyond the purview of their limited use cases.
 
  Sincerely,
  Joseph
 
  --
  You received this message because you are subscribed to the Google Groups
  Google Web Toolkit group.
  To view this discussion on the web visit
  https://groups.google.com/d/msg/google-web-toolkit/-/odd9_XG1AHAJ.
 
  To post to this group, send email to google-web-toolkit@googlegroups.com
 .
  To unsubscribe from this group, send email to
  google-web-toolkit+unsubscr...@googlegroups.com.
  For more options, visit this group at
  http://groups.google.com/group/google-web-toolkit?hl=en.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-web-toolkit?hl=en.




-- 
ISC. Daniel Mauricio Patiño León.
Liondev S.A. de C.V.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.