一直不太明白service层的作用，有时候甚至感觉service层可有可无。
dao层中已经有操作数据库的方法了，为什么还要service层去封装？有什么好处？
首先是mvc三层架构
mvc三层架构
三层架构就是为了符合“高内聚，低耦合”思想，把各个功能模块划分为表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）三层架构，各层之间采用接口相互访问，并通过对象模型的实体类（Model）作为数据传递的载体，不同的对象模型的实体类一般对应于数据库的不同表，实体类的属性与数据库表的字段名一致。
三层架构区分层次的目的是为了 “高内聚，低耦合”。开发人员分工更明确，将精力更专注于应用系统核心业务逻辑的分析、设计和开发，加快项目的进度，提高了开发效率，有利于项目的更新和维护工作。
mvc的主要作用是什么---------->分层、解耦
如何分层？
1、数据层不包含任何代码，只有数据库，还有相关的存储过程。
2、数据访问的逻辑就都放在业务层
3、页面的展示在视图层
这种分层体系结构具有以下四个优点：
（1）避免了表示层直接访问数据访问层，表示层只和业务逻辑层有联系，提高了数据安全性。
（2）有利于系统的分散开发，每一个层可以由不同的人员来开发，只要遵循接口标准，利用相同的对象模型实体类就可以了，这样就可以大大提高系统的开发速度。
（3）方便系统的移植，如果要把一个 C/S 的系统变成 B/S 系统，只要修改三层架构的表示层就可以了，业务逻辑层和数据访问层几乎不用修改就可以轻松的把系统移植到网络上。
（4）项目结构更清楚，分工更明确，有利于后期的维护和升级。
Service层的作用
service层属于三层架构中的业务层，业务逻辑是放在Service中的, 之前单调的认为service层就是生成一个dao层的对象，然后调用dao层的方法就好了，造成这种感觉只要是由于以下原因。
Service层在业务逻辑不复杂的时候，似乎是没有什么用，但是随着应用迭代业务逻辑变得复杂了之后，这一层是非常有用的。
Service层在业务逻辑不复杂的时候，似乎是没有什么用，但是随着应用迭代，业务逻辑变得复杂了之后，这一层是非常有用的。
主要表现在这几个方面：
1、更适合用来处理复杂的业务逻辑，可能会涉及多张表的操作，甚至还混杂着消息投递、接口调用等一系列的复杂综合性事务，这也是我们常说的事务管理所处的层次。
2、对表现层的复用支持，往往我们一个业务逻辑处理，不会单单只应用在一个API接口或页面上，如果直接把这部分内容写到Controller中，那当出现重复操作的时候就会产生复制黏贴，以后再要维护这段逻辑就麻烦了
3、对单元测试的支持，通过单独的一层service实现业务逻辑，那么对于业务逻辑的单元测试会更容易编写，只需要对service来编写就可以了；而web层的单元测试就不需要关注业务本身，只需要关注反馈格式就行了；不然web层就既要考虑业务逻辑的计算，还要考虑web反馈的格式验证，太过复杂。
4、业务逻辑的组装支持，因为Controller中依赖的是Service接口的定义，而具体实现可以有很多种，随着不同的需要可以注入不同的实现，可以比较好的实现多种业务逻辑版本共存。而如果直接把业务逻辑写了Controller，再要替换的时候，就比较麻烦了。
所以，Service层的设计是非常有必要的，这在单体应用的可维护性和可测试性上都占据了非常重要的地位。
service层存在的意义，就是为了方便扩展和维护。
