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

[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 ?

 

[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

[Sanjiv Jivan]

Hi fabio,

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

Sanjiv

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[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)

> --
> 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.

[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.

--

ISC. Daniel Mauricio Patiño León.

Liondev S.A. de C.V.

[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,

[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+unsub...@googlegroups.com.

[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.

> To post to this group, send email to google-web-toolkit@googlegroups.com.

> To unsubscribe from this group, send email to

> google-web-toolkit+unsub...@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+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[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.

[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

[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.

[fabio]

OK I'm pretty convinced now, I will give RF a try !

[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

--

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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.