This is a work in progress!

There seems to be a lot of debate lately on whether DTOs (Data Transfer Objects) are a good idea. Seems as though the Hibernaters are now saying "without EJB to muck things up, why do I need DTOs - they were just a hack pattern to get around the problems with EJB". Well, as much as I approve of throwing EJB out of many solutions, I think jettisoning DTOs as well is throwing out the baby with the bathwater.

Here's why: I happen to still think that we should tier systems (logically, at least), and as such, have a services layer that defines the boundary between the front and back-ends of our systems. I think most people still agree with that notion. Why do I like service layers? Generally, because they decouple the business rules end of the system from the presentation end, and through decoupling, promote the separation of concerns. Of course, if you're no longer tiering your systems you can ignore my arguments.

So, what are the concerns of which I speak? The way I see it:

The concerns of the front-end are:

• presenting data to the user
• gathering data from the user
• performing minimal data checks
• navigation through the system
• security

• getting/storing data
• performing maximal data checks
• carrying out business rules
• defining and executing transactions
• security

The creation of a service layer promotes separation of concerns by creating a "facade" (the service interface) between the front-end and the back-end. It's clear (to me, anyway) that business logic belongs behind the facade, and anything that sneaks though the facade from the service to the front-end represents a possible "leak" that can be costly in the future. Prevent the leak by communicating with the front-end via DTOs. Because DTOs are stupid data holders, they convey very little about the implementation of the service. Having clients communicate with services only via DTOs promotes decoupling by keeping the front-end of the system ignorant of the workings of the back-end.

The other alternatives, as I understand it, are to allow the client to access the domain model, either 1) directly, or 2) via a service interface.

The first approach just feels wrong to me, having argued for a service-based architecture in the first place. In my experience, when domain objects are exposed directly to client code, the two have a tendency to become intermixed, which anyone will admit to be a bad thing. A service-based approach at least draws a line in the sand to make it obvious when rules are being broken.

The second approach still has problems, even though it makes use of a service-based architecture. If the service is implemented in terms of the domain model, then we've just negated, or at best muddied, the reason for having a service in the first place. Our pretty facade has sprung a leak, and one that's very difficult to patch. Our domain objects are now subject to possible misuse by front-end coders, who also, because they are now coupled to the domain model, will resist changes to it. Additionally, the domain model is subject to usage patterns for which the domain implementors didn't plan. These new usage patterns may break important invariants or constraints that service implementations were intended to enforce. Having lost control of the domain model, we also won't be as free to change the way we implement our services, say from a thin service implementation to a thick one. These are all basically the same problems that occur when we give clients direct access to the domain model with no intervening service.

Conclusion

Objects are recast at system boundaries for a reason: decoupling. The front-end of the system, in the majority of cases, needs only to pass us simple data structures, and to receive simple data structures in return. It does not need (nor does it really want, due to the responsibility that comes along for the ride) access to the full domain model.