Alternative to DTO's

765 views
Skip to first unread message

J D

unread,
Aug 11, 2011, 4:57:07 PM8/11/11
to Google Web Toolkit
Hi,

I was wondering if there is an alternative to using DTO's to send
persistent objects from server to client and vice versa that is
compatible with Google App Engine. The objects are persisted through
JDO. I would appreciate it if you could provide some suggestions.
Thank you.

J D

objectuser

unread,
Aug 11, 2011, 5:34:20 PM8/11/11
to google-we...@googlegroups.com
What is the problem with DTOs that you're looking to avoid?  The duplication?  Being more specific might help people give you relevant suggestions.

J D

unread,
Aug 11, 2011, 5:47:09 PM8/11/11
to google-we...@googlegroups.com
Yes, I'm trying to avoid having to duplicate, and convert between the DTO and the persistent object, because I'm worried that the increase in number of DTO's will result in too much repetition of code.

Pavel Byles

unread,
Aug 11, 2011, 6:05:58 PM8/11/11
to google-we...@googlegroups.com
You can try RequestFactory.

On Thu, Aug 11, 2011 at 4:47 PM, J D <narusa...@gmail.com> wrote:
Yes, I'm trying to avoid having to duplicate, and convert between the DTO and the persistent object, because I'm worried that the increase in number of DTO's will result in too much repetition of code.

--
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/-/LwpOV-3Asp8J.

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.



--
--
Pav

objectuser

unread,
Aug 11, 2011, 6:08:46 PM8/11/11
to google-we...@googlegroups.com
Totally valid concern.

A lot depends on your situation and the purpose of your app.  One alternative is the RequestFactory.  I've not used it myself, however.

Another alternative is to just detach your domain objects and send them to the client.  You'll want to be sure there's nothing in there you don't want your client to see, of course.  And then you might have some conflicting needs between making your model good for business purposes vs. making them convenient for your UI.

Personally, I'm not a big fan of DTOs, but, in GWT-land, I think they make a lot of sense.  I don't have a 1-to-1 mapping of domain object to DTOs, but rather try to design my DTOs for a particular UI need.  It's still more work, but (I think) my UIs end up being better, stronger, faster ... whoops, got carried way. :)

But YMMV.

J D

unread,
Aug 11, 2011, 6:13:57 PM8/11/11
to google-we...@googlegroups.com
Thank you for your suggestions. I will look into them promptly. 

Cristiano

unread,
Aug 11, 2011, 7:08:14 PM8/11/11
to Google Web Toolkit
I exchange directly JPA annotated POJOs between the client and the
server, and I persist the same objects within the servlet. GWT
compiler ignores the annotations, the servlet use them for
persistence. I do not use RequestFactory (I've not yet studied it,
probably I'll use it in the future but for other reasons), I'm using
GWT RPC and it works well.
I like this approach as I achieve minimal duplication with only one
class in the GWT's shared folder,
but there might be some side effect in some specific cases (all the
persistence logic has to be handled on the server side).

Cristiano

Juan Pablo Gardella

unread,
Aug 11, 2011, 9:58:20 PM8/11/11
to google-we...@googlegroups.com
What's JPA implementation are you use?

2011/8/11 Cristiano <cristiano....@gmail.com>
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

J.Ganesan

unread,
Aug 15, 2011, 7:51:08 AM8/15/11
to Google Web Toolkit
Give DataStoreGwt a try. It does exactly what you require. It helps
you to persist client-side objects to Google App Engine directly and
retrieve them. No mediator like JDO or RequestFactory is required.

J.Ganesan
www.DataStoreGwt.com
Reply all
Reply to author
Forward
0 new messages