若是DAO，Service，Controller返回的数据实体结构一致，咱们该怎么办？

若是DAO返回的实体结构，恰好也符合Service想要返回的实体结构，恰好也符合Controller想要返回的实体结构。咱们该怎么办？

仅我的观点

按照较为规范的开发流程，咱们会经过需求分析出Controller返回实体的结构，根据“下层为上层服务，以目标为导向”的原则，设计出Service层返回的实体结构，同理设计出DAO层返回的实体结构。三个实体结构一致，说明咱们只是简单的返回数据库数据。

DAO层和Service层的分离是比较完全的，DAO和Service没有一一对应的关系，DAO具备复用性。DAO层的实体必定是申明在DAO相关包下的（好比com.demo.dao.entity包下）。Service可否直接使用DAO的实体做为返回呢？

若是使用，则Service的接口抽象和DAO的接口抽象发生了绑定，这意味着，若是DAO的返回实体结构发生了变化，则Service的接口抽象也会跟着发生变化。而DAO和Service是分离的，因此DAO的开发人员不知道也不对Service的此次变化负责。当DAO的抽象发生变化时，Service的开发人员须要判断新的返回实体是否依然符合Service这个接口的抽象（也就是说，是不是业务的变化致使了这个变化），若是符合，说明业务发生了变化，此时Service接收这个变化，并将变化辐射到了Controller；若是不符合，说明DAO修改后的返回实体已经不符合当前Service接口的要求，此时Service须要申明本身的返回实体，修改此接口的抽象，Controller依然会被变化辐射。

若是Service返回实体不使用DAO返回实体，当DAO返回实体发生变化时，Service开发人员须要关注此次变化，这是他做为依赖方的必要工做，此时他须要根据业务逻辑判断，Service的返回是否应该发生变化：若是须要则修改Service返回实体，这就改动了Service的接口抽象，这个变化就会辐射到Controller；若是不须要则Service将会本身消化这个DAO的变化，则这个变化不会辐射到Controller

Controller和Service的状况同理，结论就是，若是Controller和Service的返回实体发生了绑定，则Service的抽象发生变化必定致使Controller的抽象发生变化，若是不绑定，则Controoler的抽象有可能受影响，有可能不受影响。

可是，有一点和Service不同，Controller的返回值依托的是HTTP协议（大多数状况下来讲是这样。但有时不是，好比Spring Cloud微服务体系，经过Feign API项目嫁接在一块儿的两个项目，虽然在网络上经过HTTP协议交互，但其实质仍是Java语言层的数据交换），而不是像Service的返回同样依托编程语言的类型检查。这意味着，Controller的接口抽象比Service的接口抽象有更宽松的自解释权，Controller更关心你返回的具体数据是什么，而不是你返回的数据的类型。换句话说，就算变化辐射到了Controller，Controller也拥有较大的自由度，在不改变接口（这个接口指的是Http api）的前提下适应变化。

因此我认为，在题目所述的状况下，可使用绑定，绑定能够减小系统传递数据时的内存消耗；避免了开发时写一堆呆萌的设值代码。而面对需求变化时，咱们能够经过增长新接口的方式实现，并不须要经过修改现有接口，若是是数据库变化这样的剧烈改动，那系统也只能是忍着疼痛了，由于就算不绑定，DAO层发生的接口抽象的变化，必定会辐射到Service层，Service层却是有能力吃下这个变化，但每每并不能如愿，况且从系统结构的角度来讲，Service和Controller是靠的很近的，Controller响应Service的变化，通常不是很吃力的事情。

在使用绑定的状况下，要注意，不是你本身的返回实体，不要动（注解，注释，代码都不能动，由于它不是你的东西）。好比Controller不能由于本身的业务须要改动Service的返回实体结构，Service不能改动DAO的返回实体结构。除了你要明确你所使用的实体你是否能够改动外，你还要根据整个项目的公约来，假如架构师要求每一个层次的返回实体必须明确区分，那你也只能忘记这篇博客所说的东西，老实的建立本身的实体。最后，博客用从DAO到Controller都同样的状况作为例子描述观点，但分开来判断任何相邻两层的绑定，都是适用的。