如果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的情况同理，结论就是，如果Co