Hi,
I don't want to comment on the design decisions (maybe others will).
But what you could do in your current situation to keep the web app
(your UI's server part) stateless, is probably to just retrieve the
object _again_ from the backend by looking it up via its ID. I hope,
the business tier provides a method to do that, and that it is
efficient. Also, the business tier will have to do the necessary
security checks, because if the ID isn't stored in the stateless
webapp, and you just use the ID that is send from the browser, your
users could send potentially any ID (it's easy to modify a web
client :-) I would place those security checks in the business tier
anyway.
Chris
On Apr 15, 8:04 am, boz boz...@gmail.com wrote:
My current project has been struggling lately with the use of
immutable objects and/or properties of objects from the business
layer. I wonder how common this is and interested in any
recommendations.
The project is divided between our group, which makes the UI with GWT
(and Ext GWT, aka GXT), and a remotely located group that develops the
business layer. The business layer defines domain classes such as
entities etc. that we generally refer to as DTOs (not the best name, I
think, but that's another story). So, for example there is a DTO
called OrderDTO which has a list of LineItemDTO. You get the idea.
These DTOs are generally not GWT-serializable so the UI has to create
parallel objects which are (GXT ModelData types we call MDOs), and
translate between the DTOs and MDOs. The whole need to have translated
objects is a pain, but that too is another story, so let me get to the
point.
The DTOs lately have been modified to have immutable properties. For
example, the OrderDTO's ID and dateOrdered properties might be
immutable. This seems like a good idea to the business layer
developers but causes the UI headaches since it makes it harder to do
the MDO-to-DTO translation. Still, that's not too bad since it tends
to be a constructor call with arguments for immutable properties.
But it gets worse, IMHO. The business layer now also wants to put
properties in the DTOs that must still be in the DTO when sent back to
the business layer. That is, the DTO must be held and sent back as the
same instance. This creates a real problem because the UI must hold
the DTO on the server and then be sure to use the same instance for
updates (etc.) instead of simply making a new instance based on
properties from the MDO.
This kind of use of immutability is forcing us to bring server-side
caching into the UI design, not for performance, but for storing DTOs.
I'd much prefer to have state in the UI only be in the browser while
keeping the server-side essentially stateless. But I'm not sure if I'm
in the norm or if the business layer folks are. What to you think?
Many thanks in advance,
boz
ps: I'm not against immutability. Generally I think it's a good thing.
But is it right in this context?
--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
