Spring MVC Best Practices for implementations DTOs/ViewModels for Large application?

Question

Let's say we have a large web project with well over 100 entities using Spring 3.2.4, Hibernate 3.6.10, etc. Most of the controllers in this project will be REST-based and will be called via JavaScript.

While I think it's easier conceptually to simply marshal/un-marshal entities directly to the view, it turns out that this is very bad in practice when using Jackson. While @JsonIgnore can be used to avoid infinite recurions, there are times where this "one-size-fits-all" annotation doesn't quite work for the whole application - I need a scalpel sometimes, and many times an object can be viewed in many ways.

Also, despite using the Hibernate module for Jackson to solve issues when using Hibernate, I still run into some javaassist lazy initialization problems when using the Spring MVC test framework anyway.

All of these above problems can be avoided by simply using ViewModels or DTOs, so that's the direction I'm leaning towards. Unfortunately, creating and maintaining over 100 DTOs and the code that maps to-and-from is quite an investment.

I am also guessing that I will have to code custom JsonDeserializer classes for each of these DTOs, and this is quite a bit of coding and testing as well.

Lastly, I am unsure if this is wise, but I suspect that my validation rules will be moved from my entities and onto my view models. I probably will never actually need validation on my actual entities, but this approach makes me nervous.

Can someone please highlight some best practices for implementing and mapping DTOs in such a project, and also give some insight on the best ways of handing Deserializion? I am looking for practices that lead to easily maintained code, and hopefully not a lot of manual, time-consuming labour. Martin Fowler's assembler approach is a bit much for me. Thanks!

Answer 1

Often, at least in larger applications is my experience, the things we display on the screen are different (model-wise) then the actual business components. What you basically want is a different domain for reading and for writing (CQRS might be a way).

It is not possible to create an optimal solution for searching, reporting, and processing transactions utilizing a single model (Greg Young)

What has worked for me in the past is, to create a database view for those screens/models that differ to much and simply implement another hibernate entity (read-only) on those views. Make sure that you can relate back to the original business entity for the actual business logic you want to invoke.

If that is also a bit to much, you might want to take a look at Dozer which can help you to map from/to objects. This way you can maintain the conversion logic in Java and don't have to write all the mapping logic yourself (you still need to configure it but that is probably less painful).

Links

1. CQRS
2. CQRS Documents pdf
3. Dozer