> 人生要不是大胆地冒险便是一无所获。——海伦·凯勒 ## MVC中DTO、DO **DTO**（Data Transfer Object）：`数据传输对象`，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。 **DO**（Domain Object）：`领域对象`，就是从现实世界中抽象出来的有形或无形的业务实体。 > 当然，在MVC中还有VO、PO等概念。模型归模型，落地的时候，VO转DTO、DTO转DO、DO再转PO，我想很少有公司严格按照这样的规范来实施的。想要理解其不同，推荐这篇博文阅读一下——[《DTO与DO的区别大家可能会有个疑问》](https://blog.csdn.net/pyfysf/article/details/106394616)。此处不再展开。 在MVC模型中，DTO与DO的应用时序关系是这样的：  - Controller与Service数据传递使用DTO，DTO作为参数开始执行业务处理。 - 当然，不是Service中的所有方法都会以DTO作为入参。 ## MVC该是什么结构 我相信大家一开始学习JavaWeb的时候，便开始写MVC了。然而，我也接触过不少团队的项目，发现MVC的使用过程中实际看到了两种模型，如下图所示：  首先，我想我们先达成一种共识： - Service中引用其他业务的Mapper是一定会存在的。 - Controller中无论如何不允许直接引用Mapper中方法。 - 如果Mapper中取出的结果在多个Service中都需要进行进一步数据处理，那务必在业务Service中对Mapper进行封装后，再使用到其他业务Service中。 但是，需要注意的是，Mapper一定会有恰当的Service与之匹配，合理的做法是，Service尽量封装与之业务相关的Mapper方法。 显然，在某一模型的Service中使用其他模型的Mapper很容易造成代码模块混乱。 出现这样的原因是，开发人员没有找到侧重业务模型的Service中完成业务逻辑的编写导致的。