About DTO, ViewObjects and friends

A few weeks ago at the DDD forum a user (plind69) asked a question about how to send business objects to the presentation layer but have them show only a subset of data based on security settings. Needless to say, this is a much debated topic as witnessed by the large response and variety of opinions. Most solutions where based on the idea of DTOs, weather they are static or dynamic with proxies.

Users that had used DTO in a solution know how painful they can be: for starters DTOs are hard to maintain since every time a domain class changes so must the DTO (and also their assemblers/desassemblers). Then, there is this strange code-smell feelilng that you're duplicating code all over just for the presentation to use. To avoid this some suggest using dynamic DTOs (a nice dynamic DTO framework can be found here).

Although somewhat similar to dynamic DTO, some suggested using dynamic proxies to restrict the view. The solution looks promising for the particular issue of restrict certain fields, but I still believe that other issues should be accounted that are not possible to address with this particular implementation, like the fact that sometimes there are performance implications that make it undesirable to expose domain objects directly. Per example, imagine a fictional complicated purchase algorithm. If the result is calculated on the server, there is no need to send the actual value but a cached value. DTOs are perfect for the task since all its members are cached values. A DTO is basically only a cached set of data from the domain.

So, is there a solution? I don’t know J. First of all, let me tell you that I don't believe there is a silver bullet (at least not that I found) to solve this issues. I think that the mechanics of how to present domain classes to the user (or WS for that matter) should be considered on a use case-by-use case basis.

Maybe using a mix of adapter and proxy pattern could make life easier? A domain object could be proxified to return (or not according to security permissions) the information from the domain object itself, but if needed it could return a cached value. This could be similar to how you use a mock object but instead of creating all mock interfaces by default you pass in the actual domain object. So assuming you could do something like this:

VO viewObject = new VO(personRepository.ForId(1));
viewObject.cacheValue(“complexProperty”).returnValue(complexValue);
viewObject.restrictView(“restrictedProperty”).throwException(IllegalAccessException.Class);

In this way when you accessed regular properties or method, the information will be requested to the actual Person class; if you request a getComplexProperty you will be returned the cached value and if you request getRestrictedProperty you will get an IllegalAccessException. Also I don't think this approach is usuable in the case of Web Services (DTO seem more appropriate here).

So, what do you think? Is this practical or even possible? How do you feel about the different approaches?