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 <[email protected]> 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 [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.
