设计模式之美12-- 分层的优点, BO,entity,VO区分的好处

**为什么要分MVC三层开发？**

我们刚刚提到，大部分业务系统的开发都可以分为三层：Contoller层、Service层、Repository层。为什么我们要分层开发？很多业务都比较简单，一层代码搞定所有的数据读取、业务逻 辑、接口暴露不好吗？你可以把它作为一道面试题，试着自己思考下，然后再看我下面的讲解。 对于这个问题，我总结了以下几点原因。 **1.分层能起到代码复用的作用** 同一个Repository可能会被多个Service来调用，同一个Service可能会被多个Controller调用。比如，UserService中的getUserById()接口封 装了通过ID获取用户信息的逻辑，这部分逻辑可能会被UserController和AdminController等多个Controller使用。如果没有Service层，每个 Controller都要重复实现这部分逻辑，显然会违反DRY原则。 **2.分层能起到隔离变化的作用** 分层体现了一种抽象和封装的设计思想。比如，Repository层封装了对数据库访问的操作，提供了抽象的数据访问接口。基于接口而非实现编程的设计思想，Service层使用Repository层提供的接口，并不关心其底层依赖的是哪种具体的数据库。当我们需要替换数据库的时候，比如从MySQL到Oracle，从Oracle到Redis，只需要改动Repository层的代码，Service层的代码完全不需要修改。 除此之外，Controller、Service、Repository三层代码的稳定程度不同、引起变化的原因不同，所以分成三层来组织代码，能有效地隔离变 化。比如，Repository层基于数据库表，而数据库表改动的可能性很小，所以Repository层的代码最稳定，而Controller层提供适配给外部使 用的接口，代码经常会变动。分层之后，Controller层中代码的频繁改动并不会影响到稳定的Repository层。 **3.分层能起到隔离关注点的作用** Repository层只关注数据的读写。Service层只关注业务逻辑，不关注数据的来源。Controller层只关注与外界打交道，数据校验、封装、格式 转换，并不关心业务逻辑。三层之间的关注点不同，分层之后，职责分明，更加符合单一职责原则，代码的内聚性更好。 **4.分层能提高代码的可测试性** 后面讲单元测试的时候，我们会讲到，单元测试不依赖不可控的外部组件，比如数据库。分层之后，Repsitory层的代码通过依赖注入的方式 供Service层使用，当要测试包含核心业务逻辑的Service层代码的时候，我们可以用mock的数据源替代真实的数据库，注入到Service层代码 中。代码的可测试性和单元测试我们后面会讲到，这里你稍微了解即可。 **5.分层能应对系统的复杂性** 所有的代码都放到一个类中，那这个类的代码就会因为需求的迭代而无限膨胀。我们知道，当一个类或一个函数的代码过多之后，可读性、可 维护性就会变差。那我们就要想办法拆分。拆分有垂直和水平两个方向。水平方向基于业务来做拆分，就是模块化；垂直方向基于流程来做拆 分，就是这里说的分层。

**BO、VO、Entity存在的意义是什么**

实际上，我更加推荐每层都定义各自的数据对象这种设计思路，主要有以下3个方面的原因。

• VO、BO、Entity并非完全一样。比如，我们可以在UserEntity、UserBo中定义Password字段，但显然不能在UserVo中定义Password字段，否则就会将用户的密码暴露出去。
• VO、BO、Entity三个类虽然代码重复，但功能语义不重复，从职责上讲是不一样的。所以，也并不能算违背DRY原则。在前面讲到DRY
  原则的时候，针对这种情况，如果合并为同一个类，那也会存在后期因为需求的变化而需要再拆分的问题。
• 为了尽量减少每层之间的耦合，把职责边界划分明确，每层都会维护自己的数据对象，层与层之间通过接口交互。数据从下一层传递到上一层的时候，将下一层的数据对象转化成上一层的数据对象，再继续处理。虽然这样的设计稍微有些繁琐，每层都需要定义各自的数据对象，需要做数据对象之间的转化，但是分层清晰。对于非常大的项目来说，结构清晰是第一位的！

既然VO、BO、Entity不能合并，那如何解决代码重复的问题呢？
1,为了分层清晰、减少耦合，多维护几个类的成本也并不是不能接受的
2，使用组合和继承的方式