返回给前端的json对象这样的数据是应该放到controller层还是service层封装呢

Question

一些类似新增，修改之类的接口，放在service层，可以做事务控制等等，这个感觉比较清晰．但是对于一些查询的接口，比如涉及到很多个表的查询．个人认为如果放在controller层，会使controller太厚重，而且需要调用多个service方法，导致service层暴露过多接口，这些方法中有很多可能仅仅是透传dao；但如果放在service层，service又不可避免地带入一些展示的逻辑．请问大家都是怎么做的？

Answer 1

题主，您好

关于这个问题，根据单一职责的原则，Controller层理应不应该包含业务逻辑，它只需要将Service的结果返回至前台。
而对于Service层，个人更建议采用重构或者设计模式等方法，实现更简洁的调用。

个人愚见，希望能对您有所帮助。

Answer 2

个人感觉应该在controller层。一般service返回对象，controller 进行数据封装。举个例子，你现在有APP 端和web端，我web 需要的格式是{'success':true|false} APP需要的格式是 {'code':0|1|2},如果在service 返回json 那么你代码复用性会很差。记住，程序内传参用 对象，程序间传参用json|xml,

Answer 3

这一块没有非常明确的划分界限，一般来说，业务逻辑较为固定，会放在service层，然后封装成固定的对象与controller交互，controller根据展示要求，进行响应的封装，包括多对象组合，头部信息拼接，格式转换等等。

比如多表A,B,C，如果大多数情况A,B,C需要联查，那就把联查放到service层，将查询结果封装为对象返回给controller，如果更多的是单个查询，或者AB联查，BC联查，可以将结果的拼装放到controller层，以满足多种不同的排列组合情况。当然你也可以完全按照单一职责，一套查A，一套查B，一套查AB，一套查ABC，只是比较冗余。

还有一些情况，比如对性能有要求，那在service执行一次大查询sql比执行多次sql后拼装要效率的多；对于复杂展示结构，比如树形，那可能就需要service尽量只返回规范的数据对象，controller调用固定方法进行结构拼装。

这一块业务和权责的设计和划分，没有绝对的对错，可以找一个基本的出发点，比如代码行数少，或者易理解易用，有条件的话，前期需求设计阶段，多进行几轮，做好类和方法的关联和设计，在满足需求的基础上，后续可以通过多次重构来改善。