Domain Objects are OK for small projects, but when you application grows to have dozens, or hundreds, GWT has to build serializers/de- serializers for each of them, and the size of your javascript grows fast.
Ask yourself: what do you do with domain objects then in the UI??? they have to be decomposed in some way for display, in a form, in a table, and then that code is domain object specific. You have to do client side formatting of Date's, Doubles, etc, and this is a few orders of magnitude slower in javascript. So is sorting a list(Table). Imagine you have a query that returns 5000 objects to be displayed in a table - do you send them all to the UI??? Another pitfall, it that many people use Hibernate, JDO, JPA, etc to read/store objects, and that architecture will have you in the mindset of sending domain objects from the UI and thinking: OK, Hibernate, I have a domain object, just save it to the database. Bad idea. Never trust the UI !!!! moving to a UI-centric view of data transfer will decouple you from domain object implementations, eliminate irritating things like not being able to serialize objects with toolkit specific Annotations (Spring, Hibernate ) - but I think my biggest "win" is that with more generic UI data models, I was able to build more generic components ( Widgets ), but my more generic, I mean LESS kinds of components, and get much more re-use out of them, and my compiled codebase shrank dramatically. I can change the entire implementation of the backend, and not have to change the UI. I can use multiple kinds of widgets with a simple data model ( a Form displaying one row from a Table ), I can swap out one widget for another and not change the backend. I now have a library of reusable widgets, generic data models, and transformation/formatting/sorting/ filtering/validation/persistence utilities on the server ( where they run much much faster ) At first, JSON looked like a great generic transfer, but I found it was a bit much for my needs, in bandwidth, and deserialization. XML was worse. I'm more keen on the SDO like patterns http://en.wikipedia.org/wiki/Service_Data_Objects On May 26, 7:18 am, hezjing <[email protected]> wrote: > Hi Dean > You raised an interesting point which I had never think of it ... > > On Tue, May 26, 2009 at 5:42 PM, Dean S. Jones <[email protected]> wrote: > > > > > As I have posted here numerous times, you will one day regret having > > "domain objects" used in your GUI. Better to factor down to the few UI > > "display" generic models ( tables, trees, forms, etc ) > > Do you mean we should avoid passing domain objects (or the DTOs) to the GUI? > > Instead of returning the domain objects, the RPC service should return the > "models"? > For example if I want to display the user's details on a table, the RPC > service should return a list of strings containing the user details instead > of a list of users (List<User>)? > > It would be very helpful if you are able to show me some examples, thank > you! > > -- > > Hez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
