大型应用程序的实现 DTO/ViewModel 的 Spring MVC 最佳实践？

Question

假设我们有一个使用 Spring 3.2.4、Hibernate 3.6.10 等的包含 100 多个实体的大型 Web 项目。该项目中的大多数控制器将基于 REST，并将通过 JavaScript 调用。

虽然我认为在概念上直接将实体编组/取消编组到视图更容易，但事实证明，在使用 Jackson 时，这在实践中非常糟糕。虽然@JsonIgnore 可用于避免无限递归，但有时这种“一刀切”的注释对整个应用程序并不完全适用——有时我需要一把手术刀，而且很多时候可以查看一个对象很多方面。

此外，尽管在使用 Hibernate 时使用 Jackson 的 Hibernate 模块来解决问题，但在使用 Spring MVC 测试框架时，我仍然遇到了一些 javaassist 延迟初始化问题。

所有这些问题都可以通过简单地使用ViewModels 或DTOs 来避免，所以这就是我倾向于的方向。不幸的是，创建和维护 100 多个 DTO 以及相互映射的代码是一项相当大的投资。

我还猜想我必须为每个 DTO 编写自定义 JsonDeserializer 类，这也是相当多的编码和测试。

最后，我不确定这是否明智，但我怀疑我的验证规则将从我的实体转移到我的视图模型上。我可能永远不需要对我的实际实体进行验证，但这种方法让我很紧张。

能否请您重点介绍在此类项目中实施和映射 DTO 的一些最佳实践，并就处理反序列化的最佳方式提供一些见解？我正在寻找能够导致易于维护的代码的实践，并且希望不是大量的手动、耗时的劳动。 Martin Fowler 的汇编方法对我来说有点多。谢谢！

Answer 1

根据我的经验，至少在更大的应用程序中，我们在屏幕上显示的内容通常与实际的业务组件不同（模型方面）。您基本上想要的是一个不同的阅读和写作领域（CQRS 可能是一种方式）。

不可能使用单一模型创建用于搜索、报告和处理交易的最佳解决方案 (Greg Young)

过去对我有用的是，为那些差异很大的屏幕/模型创建一个数据库视图，并在这些视图上简单地实现另一个休眠实体（只读）。确保您可以将要调用的实际业务逻辑关联回原始业务实体。

如果这也有点过分，您可能想看看Dozer，它可以帮助您从/到对象映射。这样您就可以在 Java 中维护转换逻辑，而不必自己编写所有映射逻辑（您仍然需要对其进行配置，但这可能不那么痛苦）。

链接

1. CQRS
2. CQRS 文档pdf
3. Dozer