目录

• 简单的mvc结构如下：
• 原有的mvc结构改成如下：
• 这样做的好处是：

MVC是web开发中常见的程序结构

简单的mvc结构如下：

• view层：显示层。

• control层：业务层，集合了各种action。

• model层：模型层，一般和数据打交道。简单的sample：一个表对应一个model类。

其中control层调用model层的方法，实现对数据的访问。

采用这样的结构在一定程度上，可以做到代码清晰，较容易扩展，代码的管理复杂度较低。

但是如果是业务很多，逻辑又很复杂的网站，如果再加上开发人员的水平参差不齐，那必然会导致下面的情况：

• action中的代码越来越长，逻辑越来越复杂，不同action之间看起来有很多可以重用的代码， 但是真要进行重构的话，又非常困难。

• model层中包含的方法越来越多，有些方法也过于复杂。甚至在不少方法中还包含了业务逻辑。

• 代码的修改，还是牵一发而动全身。

• 代码难以进行自动化测试。

本来以为引入了mvc，程序的管理复杂度问题就高枕无忧了，但现在又面临了相同的问题了。

在mvc中再引入service层 该架构可以在很大程度上避免或者缓解上述问题。

原有的mvc结构改成如下：

• view层：显示层。
• control层：业务层，集合了各种action。
• service层。
• model层。

[服务端mvc架构.jpg]

原来的model层精简了，只与数据库打交道。

在这个结构中，control不直接和model交互，需要操作数据的时候，通过service层访问DAO层来实现。

service层做的事情，不仅仅是调用model操作数据，还会包含了大部分的的业务逻辑。整个程序的设计，也变成了针对服务进行设计。

service层：和数据的关系弱（所以不宜写入 Model 中），但逻辑又相对独立且需要重用（所以不宜写入 Controller 中）

这样做的好处是：

1、control层中的action得以精简，因为action中的一些逻辑，被重构成一个个的服务。而不同的action也可以重用服务了。最终Controller层实际上就是顺序执行各种服务，或者判断某一个服务或者循环某一个服务。

2、只负责和数据打交道的model层，相比之前的model层，也得以精简（现在的model层尽量只做最原子的数据操作，不同数据转换再处理，这边先不考虑，那是service层的事情）。

3、service层可以实现很大程度上的代码复用，程序的功能封装更清晰了。

4、由于service层更加清晰的定义了应用程序的边界，那么对于各个service方法（对应某个服务/应用），要做到自动化测试就方便多了。WEB程序如何做到能方便的进行单元测试，这是一直困扰我的难题，这样的设计似乎真的可行了~

5、开发人员的工作分配，理论上真的可以按层次划分了。只是理论上~

同时，这样的设计模式也是存在一定的缺点的：

1、层次太多，刚接触的开发人员理解起来比简单的mvc结构费时；

2、service层的设计需要一定的功力，因为action中和model层的逻辑在很大程度上转移到这里了。

但整体上看，service Layer的引入，更加清晰的定义了应用程序的边界，提供了一系列可以重用的操作集合。这对于网站的可扩展性和可维护性是非常有帮助的。

当然，如果网站的业务逻辑并不复杂，完全没必要用这样的设计。过度设计是万恶之源~

参考范例： Thinkphp，其中service和logic在业务复杂度不高的情况下，建议合并

代码参看《35-加个Service层后的MVC》