《精通Spring MVC 4》——2.2 对MVC的质疑及其最佳实践

本节书摘来自异步社区《精通spring mvc 4》一书中的第2章，第2.2节，作者：【美】geoffroy warin著，更多章节内容可以访问云栖社区“异步社区”公众号查看

尽管mvc依然是当前设计ui的首选方案，但是随着它的流行，也有很多对它的批评。实际上，大多数的批评都指向了该模式的错误用法。

2.2.1　贫血的领域模型

eric evans编写过一本很有影响力的书，名为《领域驱动设计》（domain driven design，ddd）。在这本书中，定义了一组架构规则，能够指导我们更好地将业务领域集成到代码之中。

其中有一项核心的理念就是将面向对象的范式应用到领域对象之中。如果违背这一原则的话，就会被称之为贫血的领域模型（anemic domain model）。

贫血的领域模型通常来讲会具有如下的症状：

模型是由简单老式的java对象（plain old java object，pojo）所构成的，只有getter和setter方法；

所有业务逻辑都是在服务层处理的；

对模型的校验会在本模型外部进行，例如在控制器中。

根据业务领域的复杂性不同，这可能是一种较差的实践方式。通常来讲，ddd实践需要付出额外的努力，将领域从应用逻辑中分离出来。

架构通常都是一种权衡，需要注意的是，设计spring应用的典型方式往往会在这个过程中导致系统在可维护性上变得较为复杂。

避免领域贫血的途径如下：

服务层适合进行应用级别的抽象（如事务处理），而不是业务逻辑；

领域对象应该始终处于合法的状态。通过校验器（validator）或jsr-303的校验注解，让校验过程在表单对象中进行；

将输入转换成有意义的领域对象；

将数据层按照repository的方式来实现，repository中会包含领域查询（例如参考spring data规范）；

将领域逻辑与底层的持久化框架解耦；

尽可能使用实际的对象，例如操作firstname类而不是操作string。

ddd所涉及的内容远不止上述的规则：实体（entity）、值类型（value type）、通用语言（ubiquitous language）、限界上下文（bounded context）、洋葱架构（onion architecture）以及防腐化层（anti corruption layer），我强烈建议你自行学习一下这些原则。就我们而言，在构建web应用的过程中，会努力遵循上述的指导原则。随着本书的推进，你会对这些关注点更加熟悉的。

2.2.2　从源码中学习

这个项目的名称为sagan，它包含了很多有意思的特性：

基于gradle的多模块项目；

集成了安全；

集成了github；

集成了elasticsearch；

javascript前端应用。

这个项目的github wiki页面非常详尽，能够帮助你非常容易地开始了解该项目。