Avoid domain object and DTO in GUI?
121 views
Skip to first unread message
hezjing
May 26, 2009, 7:18:22 AM5/26/09
to gwt
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 <deans...@gmail.com> wrote:
--
Hez
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
Dean S. Jones
May 28, 2009, 8:22:48 PM5/28/09
to Google Web Toolkit
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 <hezj...@gmail.com> wrote:
> Hi Dean
> You raised an interesting point which I had never think of it ...
>
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 <hezj...@gmail.com> wrote:
> Hi Dean
> You raised an interesting point which I had never think of it ...
>
Reply all
Reply to author
Forward
0 new messages