MVC中M的分层

本文转自：http://blog.csdn.net/phpkernel/article/details/7332227

在MVC模式中，通常V和C层功能职责一般都很清晰稳定，但是M层却常常显得臃肿笨拙。

C层主要是负责整体流程控制，一般规范的架构中，流程都可以用一张或几张流程图画出，那么表明流程一般都是固定的。

V层主要是负责页面呈现，可能使用smarty模板引擎，也可能是自带的模板引擎，显示的页面可能是HTML，XML或则JSON，这些种类再多也都是可以度量的，所以V层也可以说是固定的。

而M层却关系到系统的业务逻辑，随着系统不断迭代更新，M层中的内容也会不断演变，而这一层中也有很多复杂的处理，如文件读取，数据库查询，缓存策略，逻辑运算，数据加工，数据打包等等。

所以MVC三层模型中，M层是还能再做细分的，当M层有一个更精细合理的分层方式之后，我们的业务逻辑演变过程会更加的得心应手。

可以把原来的M层再分为5层：

A层： Application      应用层

B层：Business         业务层

C层：Component     组件层

D层：Datadriver        数据驱动层

S层： Systemdriver  系统驱动层

 

现在依次介绍这几个新的层：

1.Application

   应用层在最上面，其针对实际中的单个页面或则单个接口。Controller通过HTTP请求地址中的参数找到对应的Application，然后执行中指定的公共方法，比如main()，然后应用就开始启动。应用层的职责包括接受HTTP参数（一般是间接接受，比如从request对象中获取），调用Business层的特定业务，保存业务执行结果，这些结果最终会由View显示出来，当然是通过Controller协调。应用层是M层分解成五层之后最高的层，Controller会与此层直接通信。

2.Business

  业务层在应用层之下，通常一个应用实例对应一个业务实例，而一个业务有可能为多个应用服务，业务是一个执行流，它通过执行一系列的操作来完成应用的需求。这些操作来自下层的组件层Component,可能一个业务需要一个或则多个组件来完成一个完整的需求。因为一个业务实例通常只对应一个功能，所以只有一个固定的方法会被上层的应用调用，比如flow()。业务层的职责是帮应用层执行业务流并且有必要的时候返回数据给应用层，它会调用下层Component的方法。

3.Component

  从组件层开始和上面两层有一个本质的区别，组件层开始有了类库的概念。 前面两层的实例通常只暴露一个特殊约定的公共的方法让上层调用，从这一层开始一个实例会提供多个方法给上层。组件层通常和系统中一个角色对应，例如在博客系统中，博文是一个角色，用户是一个角色，那么就会有博文组件BlogComponent，用户组件UserComponent，每个角色都有对应的操作，例如博文和用户都可以添加删除修改。

  需要注意组件层中不应该有任何数据读取的操作，数据读取是下层数据驱动层来做的。如果组件层从下层获取了数据，那么它的一个职责就是对数据进行加工。例如BlogComponent有一个方法是获取一个博文getBlog($id)，那么getBlog()方法中，从数据驱动层中取得了对应id的博文数据之后，需要对博文数据进行一定的处理，比如将博文中的HTML特殊标签过滤等等。组件层不关心数据的读取方式，但是会关心数据的结果，比如数据不存在或则数据已经过期。

4.Datadriver

  数据驱动层的职责是为组件层提供源数据，此层关心数据的存取介质，存取方式等等。数据可能被存储在DB，MC，Filesystem或则远程的HTTP服务器上。数据驱动层不关心数据的内容，只关心数据读取的操作结果，例如假设数据存在DB中，但是数据驱动层在执行数据库查询的时候出错了，那么需要在此层处理。 假设数据存储在远程的HTTP服务器上，那么数据驱动层需要关心HTTP返回码是否为正确的200系列或则错误的400，500系列，哪怕HTTP请求返回了错误的数据实体，但是返回码为200，那么数据驱动层也不关心，这种情况需要上层组件层来处理。

5.Systemdriver

  系统驱动层是系统环境提供的数据访问实例，例如数据库服务的Systemdriver可能是一个db handler或则，HTTP服务的Systemdriver可能是一个http handler，文件存储系统驱动层可能是一个file handler, 系统驱动层相对简单，这层可以和数据驱动层进行合并，其职责也较少。仅仅只是执行数据驱动层的数据访问指令。

 

通常情况下这五个层中，上层的实例数量比下层的实例数量要多， 整体类似一个倒置的梯形：