Service层中 = 核心功能(几十行 上百代码) + 额外功能(附加功能)

1. 核心功能
   业务运算
   DAO调用
2. 额外功能
   1. 不属于业务
   2. 可有可无
   3. 代码量很小

以及：事务、日志、性能…

Service层，作为程序的业务层面，其中最重要的必然是程序的业务流程，只有对程序的业务流程有足够的了解，才能写出优秀的Service层代码。

不冗余，是一个程序员代码水平的一个体现。

为什么要先写接口？
接口的作用是什么？

这里我引用一句话:

1

接口主要用于描述类具有什么功能，而并不给出每个功能的具体实现。一个类可以实现一个或多个接口，并在需要接口的地方，随时使用实现了相应接口的对象。——《Java核心技术卷一》

这句话所描述的是接口的扩展性。简而言就是：接口是一个统一的插座，如果有需要我们就可以直接进行调用，实现了即插即用。

例如：有一个登录功能需要我们去实现，而该系统又有多种登陆方式，我们不可能每种接口都写一个Service代码给Controller进行调用，这样是十分繁琐的。而我们将多种登陆的方式统一成一个接口，然后根据用户的需求来分配最后实际的实现类。此时对于使用者来说，他们只需要关注的是登陆这个方法，整个登陆操作变得十分灵活，根据不同的场景使用不同的方式登陆。

对于开发者来说，接口中清晰地列出了所有地方法，对于后期的维护以及修改也是有极大的方便。

Service层之间可以相互调用吗？

这个问题相信很多人都有过思考，理论上来讲是不应该相互进行调用的，因为Service层的存在的一个很重要的目的就是 解耦 。

将业务层的每一个业务独立出来，以至于他们之间不相互影响，能够实现代码的优化，否则多种业务的代码混在一起，长久之后谁都看不出来代码的逻辑。所以说Service层就实现了这一个很重要的功能。

所以如果Service层之间的代码相互调用，是不是会是一种倒退呢？

有些人可能会问，有些业务中确实是会使用到其他业务中的代码，那这部分代码怎么办？重新写？那是不可能的，这又犯了冗余这个错误。所以我们该怎么解决呢？

首先，我们要清楚，这个情况是出于Service间有通用的逻辑，而不是通用的业务，每个Service对应一个业务，业务之间应该有明确的分界，不然会出现业务间的耦合，这是设计的不合理。

既然是通用的逻辑，我们是不是又可以把他们抽象出来，独立成一个工具类，当我们需要的时候直接进行调用这个工具类就可以了呢？

所以我个人认为Service层之间是不建议相互调用的。

当我们实现一个登录功能的时候，Controller层，调用Service层，往往我以前的写法是，Service返回登录成功或者失败的代码，然后Controller进行一个判断，判断是否成功登录，然后再向前端返回信息。这样子的写法有个问题，Controller判断的一个过程，算不算是业务？如果算，是不是Controller层又接触到了业务？

又回到了之前的问题，为什么要有Service层？

所以说，我们应该让Controller层尽可能少的接触到业务，所以我们的写法可以优化为，再Service层做完所有业务相关的工作，最后返回给Controller层的是一个开箱即用的接口，这样子是不是可以避免Controller层接触到业务相关的代码呢？
这就又符合了我们使用Service层的初衷了。

在看了一些文章之后，个人的一些小小观点。