That's what I tend to do. Since I write consumer apps, passing my raw entities across the wire usually isn't an option in the first place - there's usually too much security-sensitive stuff, or at the very least data I would rather not disclose to a potential attacker.
Also... using entities client-side tends to really thin them out, and you can easily fall into the "anemic domain model" antipattern. And when you work on the domain classes, it can break your RPC protocol (forcing users to reload their browser page, or worse if we're talking about web service type RPCs). Sometimes this is ok, sometimes it isn't. Just depends on your app. As a general rule, I wouldn't be so afraid of creating DTOs. Even if they're just a set of public fields - do they really need getters and setters? Jeff On Thu, Jun 30, 2011 at 2:12 AM, Drew Spencer <[email protected]> wrote: > Thanks guys. So basically I should be grabbing the Supplies and Suppliers on > the server side, combining the data I need from both into a SupplyDTO > object, and passing that back to the client, rather than doing the > processing on the client? > Seems to make sense! > Drew > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine-java/-/B7fV3EzXtSEJ. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
