May 28th, 2009, 12:28 AM
thoughts on dtos
Firstly, great work with Roo. I was curious to know what had happened to this project as I remember you presenting it a couple of years ago so it's great to see it all come to fruition.
When you last presented on it, you had some features around managing dtos and conversion to / from domain objects. I'm curious to know both what your position on this approach is now and whether you have or intend to provide support within ROO for this in the future ? It seems that many, if not all of these ultra productive frameworks promote dealing with domain objects from web to pertistence layer which is fine in a lot of cases but not always what we want. Obviously ROO is flexible enough to allow us to implement our own service layer and dto conversion but if ROO has plans for helping make this problem simpler to work with that would be excellent!
May 29th, 2009, 10:00 PM
In the end I removed DTOs from Roo given that we shifted focus more toward productivity (and less on the pure OO/DDD concepts). DTOs still have a lot of valuable purposes, but to be honest the major motivation in my personal projects that originally motivated DTO usage was to provide a productive approach for building Generation IV clients (client-side component-based frameworks like Flex/GWT) and ensuring the UI tier could evolve independently from the database/entity layers. In recent times I have found the increasing sophistication and flexibility of JSON-to-Java mappers have delivered this by mapping JSON directly to/from JPA entities (thus mitigating the need for intermediate DTOs that are then JSON mapped). You can also do clever things like handle field-level authorization during JSON mapping and enforce read-only vs read-write fields without significant work. Obviously not all JSON libraries are equal in terms of depth, and indeed none provide advanced out-of-the-box mapping I found that useful. But I am not afraid to roll my own mapping, provided the individual property mapping phases are properly exposed for customization.
I know that people building Generation II or III clients (server-side request-response approaches and server-side component-based frameworks) still sometimes find DTOs useful, and it would be unnatural and less efficient to use JSON in such an architecture (where everything runs as Java bytecode and probably in the same physical JVM). I can see DTOs being useful there if you are willing to address the mapping issues and in particular collection management. The latter is surprisingly difficult.
As you mentioned, Roo can be used to automatically build a DTO tier. An off-the-top-of-my-head model might be to annotate entity fields with @RooMap(dtoName="SomeName", path="thePathWithinTheDtoThatThisFieldShouldBeMapp edTo"). That way you could have the DTOs produced automatically with just the required fields, and also have the Dozer mapping files produced automatically. One issue is you'd need to support one entity field being mapped to multiple DTOs, so you probably need a @RooFieldMappings(value=RooMap) style approach. Similarly a "DTO-centric services layer" could be produced automatically for the persistence operations and offering domain object delegate methods.
There is no architectural impediment to achieving the sort of approach described in the last paragraph with Roo. You'd still need to find sensible solutions to collection management and also computed fields and custom constructors typically put into the DTOs.
May 30th, 2009, 02:47 AM
Thanks for the detailed reply Ben. I've actually been experiencing some of the mind-shifts that you mention with my development and I think you've helped to convince me of one or two things. I'm seeing my back-end java code get thinner and thinner and my front end client code get more and more advanced. Once you start to look at frameworks like Sproutcore, Dojo and even jQuery, Mootools etc with a bit of extra love, the backend starts to become simpler than it used to.
I'm really keen to start using the Spring 3 REST stuff because I think it will tighten my client / server apis up a lot. I'm also going to dig a bit deeper into the json / domain mapping stuff you mentioned because i've been using my dto layer for this and maybe I don't really need to. I have a home grown framework that takes a lot of the pain of dealing with the collections and varying object graphs that might be required for different requests but it's still a whole layer of objects that may be redundant.
Do you have any recommendations for json / java mapping libraries ? I'm guessing you're probably using whatever is provided in Spring 3 now. I've been using the json-spring view that is an add-on to json-lib and that's working fairly well for me. I haven't looked into it for any advanced mapping though so I should do that.
Anyway, it's great to see a completely pragmatic approach taken with this stuff than there has been in recent years. Productivity is a real concern these days and sometimes we can just get bogged down in architectures that solve problems that really most likely won't happen for a certain class of app. Even if they do, there's other ways to solve the problem if they do happen.
May 30th, 2009, 07:56 AM
My personal favorite these days is GWT. :-) Although achieving linear-like scalability and maintaining acceptable performance, production management, security and low full lifecycle cost are still challenges, especially if opening up an application API to remote queries and employing cloud architectures in the intended manner. Still, we're witnessing the emergence of a whole new generation of web-based applications right now, and it's very exciting to be involved in developing them.
Originally Posted by robmonie
I did evaluate them a few months back and I found http://jsontools.berlios.de/ was the most flexible for what I was after. Two-way mapping and being able to hook into the processing were pretty important requirements from my perspective, and this library fitted those goals very nicely.
Originally Posted by robmonie
May 31st, 2009, 06:53 PM
Thanks for the link... I'll give jsontools a good look. I hadn't come across this one before.