mvc设计模式中请求的json解析应该放在controller还是service层？
2018-11-29 · 百度认证:云南新华电脑职业培训学校官方账号
云南新华电脑学校
我们项目里分了三层：
表现层：Spring MVC，负责接收Http请求、展现（返回）结果、简单校验
App层：提供应用层的功能，比如导入、导出、复杂校验
Domain层：处理业务逻辑，比如一些Service
在一个Web程序中，用户传过来的参数是POST／GET形式给你的
在一个Web service程序中，用户传过来的参数是json或者SOAP
在一个Swing程序中，用户传过来的参数就是字符串
调用顺序是单项的：Controller->App->Domain
且感知关系为：Controller->App->Domain，即下层不感知上层
先回答你第一个问题：
你说的第一个问题我是否可以理解为，Http请求过来的参数不是Object，而是一堆基本类型，但是你的Service接收的参数是Object。正确的做法应该是，在Controller将“生”参数转换成Object对象，然后调用Service。
为何这样是正确的？因为Service属于Domain层，里面是业务逻辑，其接受的参数应该根据自己的需要而进行设计，不应该考虑Web层过来的参数是什么，这样才可以做到在不同场景下复用。
举个例子，你的Service应该可以被复用不同表现层环境下：
如果你将Service和具体某个表现层环境绑定，那么其方法参数肯定不稳定，结果就导致无法复用。
同理，Service的返回值也不应该和具体场景绑定。
在Spring MVC层面，Controller可以很方便的把参数转换成Object，相关文档
第二个问题：
这个问题可以分为三个：
1）简单的校验比如参数长度限制、非空判断等在哪里做？
简单校验利用Spring MVC的自身提供的机制做，相关文档，相关文档
2）和Service本身的业务逻辑平行的校验在哪里做，比如用户下单时判断其是否账号被禁用
我倾向于将这些逻辑校验放在App层做，Controller调用App，App调用两个不同的Service，将业务编织起来
3）和Service本身有关的业务逻辑校验怎么做
你举的是登录的例子，用异常告知调用方（Controller）处理结果没有任何问题。你也可以丰富Service的返回值达到这个目的，不过需要注意的是，Service的返回值的设计不能和表现层环境绑定，否则就不能复用了，这也就是为什么 @YaTou[xfslove] 提到了apache-shiro采用的是异常机制处理认证失败，因为只有这样才足够通用。
