在MVC开发模式中，封装对象应该放在Controller还是Service？Controller与Service应该如何交互？

Question

已经学了两年的MVC了，但是有些概念还是很模糊，希望能在这里寻找到答案。 我曾经看到有人说Controller不负责数据处理，全部交给我们的Service来处理，网页前端传回来是什么数据类型，就直接把数据类型转发到Service，然后由Service来处理；但是又有另外一种声音说有时候会同时调用多个Service，如果在Controller就将对象封装好了，就免于在Service的方法中多次封装。 另外还有一个问题就是关于Controller与Service的交互问题。我们为了前端的客户交互良好，往往会通过Controller向前端返回一些错误提示，比如用户名已存在，用户名和密码不匹配等等。可是处理业务逻辑我们是放在Service层，那么如果把一个login(String username,String password)方法的返回值设定为boolean就无法返回多种错误，但是如果返回String类型，就需要设定一些基本的字典。我自己“奇思妙想”，我在Service中通过抛出我自定义的一些RuntimeException，然后在Controller中通过TryCatch来处理不同的错误，但是我自己认为这种抛出异常的方式不妥。最近就陷入了迷茫，马上就要开始做下一个项目了。希望各位能帮我解答一下迷惑。 感谢。

Answer 1

我觉得Controller不负责处理数据是正确的, 因为在spring-mvc中Controller是不能复用的, 但是如果你把业务逻辑抽象成Service, 那么这个Service就是可以复用的.

至于你说的 "在Controller就将对象封装好了，就免于在Service的方法中多次封装" , 没太明白什么意思, 你每个Service需要什么参数, Controller就给什么参数, 至于需要的参数是否需要封装成对象就可以自己权衡了.

你所说的login(String username,String password), 你想抽象成Service用异常处理处理多种不同的结果, 这个我觉得完全没有问题, 而且我觉得非常好啊, 很多认证框架都用的这种方式, 至少我看的apache-shiro就是用异常处理认证失败的不同情况的.

Answer 2

第一个问题感觉没有标准答案，具体情况具体分析，逻辑分层清晰易于维护就好。

第二个问题的话，你这里给出的交互是隶属于权限控制的，一般用filter、aop、代理、反射等等方式实现代码收束都可以，异常也在这些集中控制的代码里扔一次就好，直接在Controller里硬编码我反倒觉得累赘。Service这一层更多的是调用Dao层的方法来实现一些复杂的涉及多表的业务逻辑处理，事务也放在这一层（当然现在框架把这事儿都干了），所以Service这一层一般不扔异常（参数验证在Controller以及之前的层次都做掉了因此不出现业务相关异常，而Dao把数据库相关的底层异常屏蔽了）。

当然这是个人看法，没有定式，还是那句话，分层清晰易于维护就好。

Answer 3

1、Controller默认是单例的，但可用@Scope(value = "prototype")替换

2、登录可以返回int啊，自己加个枚举

3、规定是在Service层处理逻辑，要看业务的吧，代码冗余度低些好，也好优化

大家观点会不同，做开发更多的还是优化改，降低冗余度，而不是必须要怎么做。。。

Answer 4

1，Controller应尽可能的不设计业务逻辑，只涉及交互
2，Service为可复用的业务逻辑
3，Controller为Service的上级调用方
4，你这个case可以在Service中返回固定的返回值，在Controller层做判断，并抛出你想相应的异常。

当然了这只是我们目前的做法，分享一下。。。

Answer 5

封装对象到底在Controller还是Service，还是要看具体的情况，个人认为如果是简单的参数在Controller中进行封装时是完全可以的，如果放到Service反而会显得很冗余，而且导致Service通用性变差；对于第二个问题，不容同意通过枚举或者不同的状态码来在Controller左做判断抛出异常，完全可以自己定义一套异常处理机制，直接在Service层抛出，项目有针对此类业务异常的处理机制，直接两将Service的错误信息和错误码返回到View层，让客户端根据状态码和错误信息作处理