最近思考一个问题：一定要写个Service层的接口吗？Service层的接口到底用做什么用的呢？好像除了增加工作量没什么用啊？

其实，Service层在业务逻辑不复杂的时候，似乎是没有什么用，但是随着应用迭代，业务逻辑变得复杂了之后，这一层是非常有用的。

1、更适合用来处理复杂的业务逻辑，可能会涉及多张表的操作，甚至还混杂着消息投递、接口调用等一系列的复杂综合性事务，这也是我们常说的事务管理所处的层次。

2、对表现层的复用支持，往往我们一个业务逻辑处理，不会单单只应用在一个API接口或页面上，如果直接把这部分内容写到Controller中，那当出现重复操作的时候就会产生复制黏贴，以后再要维护这段逻辑就麻烦了。

3、对单元测试的支持，通过单独的一层service实现业务逻辑，那么对于业务逻辑的单元测试会更容易编写，只需要对service来编写就可以了；而web层的单元测试就不需要关注业务本身，只需要关注反馈格式就行了；不然web层就既要考虑业务逻辑的计算，还要考虑web反馈的格式验证，太过复杂。

4、业务逻辑的组装支持，因为Controller中依赖的是Service接口的定义，而具体实现可以有很多种，随着不同的需要可以注入不同的实现，可以比较好的实现多种业务逻辑版本共存。而如果直接把业务逻辑写了Controller，再要替换的时候，就比较麻烦了。

解耦：也就是在逻辑上不同的层之间，某一层的改变尽量不要去影响到其他层。 而Servlet层和Dao层都是由实际意义代码操作的层，而且两层有直接的调用关系。如果 Dao 层代码修改了，会直接影响到 Servlet 层。为了尽量的减少这两层之间的耦合，加了这么一个层

便于扩展：也就是说一份代码在初次写的时候，一手的开发者对代码的理解是相对比较充分的，但是，功能可能不是非常完善的。那么在之后修改代码的某一部分功能的时候，也是需要尽量这个功能对外仅仅提供一个调用，功能内部的代码如何实现不需要被其他部分了解。那么 Service 层作为一个中间站，就比较好的解决了这个问题。

所以，Service层的设计是非常有必要的，这在单体应用的可维护性和可测试性上都占据了非常重要的地位。

参考文章 https://didispace.blog.csdn.net/article/details/113243302 https://blog.csdn.net/qq_36654606/article/details/86618708 https://blog.csdn.net/liming11112/article/details/109962167