As a hobby project I am working on a Adobe Flex front-end with a Java back-end using JPA for persistence. The protocol I am using is remote objects (AMF) implemented with BlazeDS.

I started out with a service-facade and entity DAOs, but without any specific DTOs. The same POJOs, the domain objects, were passed in the service-facade as those used as DTOs passed to the Hibernate DAOs.

However, the latest two days I have been thinking whether this is a good approach or not. For example, say I have POJO Book with a unidirection ManyToOne relation with the POJO Category (i.e. each book may only be associated with one category, but the same category may be associated with many books). I see some alternatives:

Alternative 1:
I expose a method/operation addUpdateBook(Book book). In the implementation of this operation I add/update both the book and the referenced category. I mean, if the client submits a book having a category that doesn’t exist from before, this would mean that the client implicitly may edit categories using the addUpdateBook service.
- pro: the client is working directly with the domain model!
- con: the entire category information will be sent when a new book is added even though a reference to the category would be sufficient

Alternative 2:
I expose a method/operation addUpdateBook(Book book,Long categoryId). In the implementation I retrieve the category for the given categoryId and replace the category given in the book POJO and then I persist the book. In other words, I ignore any category in the book object, I just look at the categoryId. This means that the client would need to use another operation in order to modify the category.
- pro: the client can still work on the domain model
- con: it is confusing for the client that the category of the book object will be ignored
- con: the entire category information of the book will be sent, even if the server never will read it
- pro: it may be more clear when a separate operation should be used for category modifications
- con: I need to retrieve the category before persisting the book. I guess this means some overhead.

Alternative 3:
I expose a method/operation addUpdateBook(BookDTO bookDto). The POJO BookDTO looks as the POJO Book, but instead of a field “Category category” it has a field “Long categoryId”. In the implementation I retrieve the Category for the given categoryId before I persist the Book.
- pro: not confusing for the client
- con(?): what should the method getBook(Long bookId) return? should it return only the BookDTO? Then it would be required to invoke also the operation getCategory(Long categoryId) in order to have “the entire book information”. Then the client would need to set together the different parts to a local domain representation of the book. Compared to alternative 1 this would be more complex on the client side?
- con: I need to retrieve the category before persisting the book. I guess this means some overhead.

I guess (!) alternative 3 is the way you would design the operations in a SOA context. However, for me, it is not that important to be loosely-coupled between the client and server. My initial focus is not to provide multiple client-platform support.

Please give me your comments!

I layered a bit more…
My Generic Facades use a persistence unit, and implement CRUD functionality.
Then I have Generic Managers who implement the service/domain logic with transactions, there I use the facade interfaces to compose my service/domain specific methods.

discipline needed, developers tend to implement service/domain logic in the facade. Too common

I guess we now have three approaches on how to send data from server to client:

1. Use the actual domain objects. No translation, but not always technically possible (lazy loading!) and does not shield the client from changes in the domain model that are not significant to it.
2. Use specific DTO’s. Lots of boilerplate code but highest flexibility, both in adapting to technical issues and in shielding components from change.
3. Use generic DTO’s. Less boilerplate code but also less protection from the type system.

Which approach is best depends on a number of variables, two of which are:

1. How closely are the “client” and the “server” coupled in the development cycle? Does every change in the serer immediately mean that the client has to change anyway? For example, a Spring WebMVC view and its controllers are very closely coupled while a Flex UI and a Java backend are probably less closely coupled.
2. How closely are the “client” and the “server” coupled technically? Once again, a Spring Web MVC view communicates with its controller using Java objects in the same VM, while a Flex UI gets it objects over an AMF channel.

And that probably answers your question: in a number of cases not having DTO’s works pretty well. This is especially the case for the data structures oriented model which tends to be used in CRUD-like applications. My recommendation is to look into Service Facades and DTO’s when your interactions with the entities becomes more complex and the benefit of having an abstraction layer outweighs the added complexity of another architecture layer and the hassle of having to copy stuff in and out.

BTW, Adam Bien just blogged about a very nice way to build Generic DTO’s.