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.

Yes. I just dusted off an re-read the first few chapters of Chris Richardson’s POJOs In Action and found that the approach that I was trying to articulate is strongly influenced by reading his book back in 2006 (written pre-JPA). To summarize his writings:

* His Entities have state and behavior. They are part of the domain model.
* His Services are purely focused on manipulating entities to fulfill use case logic. They are part of the domain model. He says that where possible they delegate logic to the entities.
* The façades return detached entities as the DTOs (”POJO façades that use detached domain objects as DTOs”). They are not part of his domain model. They worry about the plumbing (loading enough data to render on screen and merging detached entities). He is explicit about not copying to DTOs with his case study of a CRUD orientated app.
* He has ‘repositories’ which can be placed today by your DAOs (but I would call them Managers or Repositories to avoid confusion with old-school jdbc backed result set mappers with no lazy-loading).

@Erik rightly points out Chapter 6 of Clean Code which says that we should be very aware of whether we are going for a data structures orientated model or a fully encapsulated object model that shields its internal fields (which we would fire DTOs into or Commands at and hide the internal fields of any entities from the client). The Chris Richardson book and my last three large scale systems fit into the data structures end of the entity spectrum. The services encapsulate the concerns of locking and workflow for the transactional use cases (in the business sense of placing an order as opposed to browsing through data) which have high complexity. Data structure like entities are exposed to the UI don’t need public setters on fields to protected their class invariants.

So my question to is what is the nature of the application for which the DTOs model is recommended in this blog? Is it a online rating engine which needs to follow a command like pattern to hide its internal fields (as recommended by Clean Code chapter 6) or is it a largely crud like app which could fit a data structures model? I feel that the type of logic expose to the client makes a significant impact on the suitability of either the exposed domain model or DTO design. Also whether the client is trusted code or not can have a big impact. If your using a plug-in on the client for UI presentation then you have different concerns about encapsulation of the domain model behind DTOs than with a Swing app or a ZK RIA webapp.

http://java.dzone.com/articles/using-desktop-model-view

With such an Exposed Domain Model approach you can either go with Open Session In View or you have to figure out how scope the transaction to a narrower scope. For scalability we prefer to scope the database transaction to a business façade. More or less the façade encapsulates the use case for the UI controller and needs to ensure that enough of the entities are loaded for rendering. The façade can re-attach the detached entities, and use queries to load more data, and merge the detached entities. The UI controller is responsible for replacing the merged entity returned from the façade into the UI model mapped to the browser screen.

If we wanted to add a new client, say some soap over jms remote system, then we would also a façade. That would load data from the xml payload (which can be considered as an xml-ised DTO), load the referenced domain entities, map the xml-dto to a new/updated entity, perform validation of the ‘command’ represented in the message, all within a transaction. The façade would re-use internal application services just like the façades for our ‘native’ AJAX front-end.

I must say I was keen to ditch the façades a while ago as they give a procedural “transaction script pattern” smell that plagued early EJB. Certainly in a small app they look like over-kill. Yet they perform a clear responsibility, particularly if we let then go straight to the DOAs occasionally as well as letting them use generalized internal services which encapsulate more complex business operations. An alternative pattern with a small app is to use something like a spring transaction template directly within the UI controller to ‘in-line’ the façade logic into the AJAX UI controller whilst minimizing the scope of the JPA session to the transaction template call-back.

http://damroo.blogspot.com/2009/02/2-dto-or-not-2-dto.html

Of course, deciding to not have a Service Facade while being mindful of the fact that you might need it later but that some cost will be associated with the refactoring needed at that time is a very good approach.