以切身体会浅谈对Controller和Service的理解

进入开发行业以来，异常，日志，业务层次划分等等看似简单的问题却让我琢磨了很久，也切身体会到工作经验不仅仅是你技术上的累积，也包含很多类似这种实际工作中的细节问题的处理，而这些却是在课堂上学不会的，只有你真的经历过了，你才会深刻的理解为什么底层异常要抛，为什么有些代码应该写在service而不是controller层。下面我总结了几个自己这一年来常常遇到的问题，并谈谈一些自己的看法，当然随着经验的累积，可能对于一些问题的理解会更透彻，现在就简单谈一下此刻的一些认识：

              1.在controller和service里都写那些代码？

                  Controller，从字面上理解是控制器，所以它是负责业务调度的，所以在这一层应写一些业务的调度代码，而具体的业务处理应放在service中去写，而且service不单纯是对于dao的增删改查的调用，service是业务层，所以应该更切近于具体业务功能要求，所以在这一层，一个方法所体现的是一个可以对外提供的功能，比如购物商城中的生成订单方法，这里面就不简单是增加个订单记录那么简单，我们需要查询库存，核对商品等一系列实际业务逻辑的处理；

              2.在整个项目中什么时候加异常？异常怎么处理？

              说到异常，我们应该回想下我们学习异常这一模块时，异常到底是什么有什么用？一直以来都觉得如果代码出现了异常是件让我悲伤的事，因为它意味着我哪里写错了，但是现在回想最初的认识都觉得有点好笑，"人，孰能无过"，我所理解的异常只是我自己认为造成的错误，但殊不知实际中的异常情况是很多的，除了自身造成问题之外，服务器down了，或者数据状态发生改变，甚至断网都可能造成异常，所以从另一方面，异常是服务于我们的，是为了我们更好的发现问题解决问题而存在的，在这里，真的由衷的敬佩创造异常机制的前辈，他们过人的智慧真让人望尘莫及~

              回到话题上，那么实际中我们该怎么做呢？个人觉得我们应该从底层的dao一直到action，应对每一层的代码进行基本的try-catch，有时根据业务需求可能要进行多个catch，由上至下依次捕获从小到大的各种异常，一般对底层的异常应该往出抛，目的是要通知上一层也就是调用者出现了什么问题，但是对于和用户直接交互的前台让用户看到后台的这些异常信息可是不妥的，所以我们需要将异常信息转换常用的友好提示给用户，而对于异常信息应记录到日志以便对问题进行分析解决。

              3.什么时候该记日志？怎么记？

              关于日志，个人觉得其实没必要想的太神秘，日志就是记录信息，可以记录一些异常信息，也可以记录一些业务日志，不过日志分了几个级别，有error 有info等等，我暂时还没细看，所以就不多说了

              4.对于参数的安全性判断应该写在controller还是service？

               数据安全性校验，当然在哪一层都是很有必要的，一般我会在controller进行一些参数合法性校验，但是这一点被组长说过几次了，建议在service层进行校验，容我好好想想怎样才合理吧~

              以上是我初次记录自己一年来困扰我最多的几个问题，后续认识有所改变或加深了再来更新，ok，就到这吧！又得赶代码了~