MVC

前面介绍了一些基础内容，涉及到了去耦的5大工具，本章开始讲介绍本书的重点：Clean Architecture，Clean Architecture通过我们之前介绍的设计模式和设计原则来设计出更好，更内聚，更clean的代码。

本文为系列文章的第六篇，前五篇地址是

The Clean Architecture in PHP 读书笔记(一)

The Clean Architecture in PHP 读书笔记(二)

The Clean Architecture in PHP 读书笔记(三)

The Clean Architecture in PHP 读书笔记(四)

The Clean Architecture in PHP 读书笔记(五)

MVC和其的局限性

mvc如今充斥在整个软件开发中，前端讲mvc，后端讲mvc， 前端：Backbone.js、AngularJS、Ember.js… 后端：Ruby on Rails、CodeIgniter、Laravel、Django… 这么多的mvc，在初学的时候，很难分辨清楚到底mvc是什么，怎么每一个mvc看上去都不怎么一样？

查看维基百科上的定义，可以看到mvc中最重要的一点是：

Model should inform View about the changes (observer pattern)

当model发生改变的时候，要主动通知view，这一项在server-side framework中基本上不可能的（当然可以通过socket等手段），因此我们平时server-side framework中声称的mvc都是不确切的，那平时我们使用的“mvc”是什么呢？

MVC mode

• View 传送指令到 Controller
• Controller 完成业务逻辑后，要求 Model 改变状态
• Model 将新的数据发送到 View，用户得到反馈

Model2 MVC

Model 2 is a complex design pattern used in the design of Java Web applications which separates the display of content from the logic used to obtain and manipulate the content. In a Model 2 application, requests from the client browser are passed to the controller. The controller performs any logic necessary to obtain the correct content for display.

model2是mvc在server-side上的实作，其中controller负责从Model和view之间的沟通。

比较下model2和mvc中各角色的区别：

我们知道了我们讨论的MVC在server端其实是model2后，下面我们为了更好的理解MVC，我们按个讨论各个模块。

MVC模块

先介绍最重要的模块Model.

Model的理解

第一件必须要阐述清楚的是：

model is a layer.

model不是什么？

model不是简单意义上的类或者对象，同时model也不是orm或者数据库表的抽象。

model是什么？

在好的mvc变种中，model包含了所有的业务逻辑，并且model layer主要是由下面三种结构组成：

• �Domain Objects A domain object is a logical container of purely domain information; it usually represents a logical entity in the problem domain space. Commonly referred to as business logic. 领域对象包含了特定的领域知识，可以理解为业务逻辑。 领域对象关注一些业务规则，譬如下单的时候要验证数据有效性，发货的时候要保证用户正确支付过等等。领域对象应该完全不关注存储，不管数据是来自redis还是mysql等。
• Data Mappers 数据映射器只负责存储，如果是mysql，则关注数据怎么从mysql中读取后转换为领域对象，以及怎么将领域对象存储到mysql中
• Services 可以将services想象成"higher level Domain Objects"，和领域逻辑不同的是，Service关注是Domain objects和Mappers之间的交互。 这些Services最终是暴露出公告接口来供其他层来使用model layer的业务逻辑。 当然，我们也可以避免services，但是不可避免的暴露些领域逻辑到controllers中。 譬如你要创建一个订单，可能会涉及到多个领域对象，这样你可以将这个抽象城一个Service，这样controller中只需要使用service就可以了，而不必和多个Domain object打交道。

此处servervice还包括了一些依赖的第三方组件和自己提供的组件，譬如你可以发认为送邮件组件是一个Service，不管这个'mail sender'是自己实现还是第三方的。

怎么和model打交道？

和model layer进行交互，应该只通过services，这样分离的好处是：

• 符合单一职责原则（SRP）
• 如果逻辑改变了，提供了回旋的余地
• 尽可能式controller保持简单
• 如果需要依赖外部api的话，尽可能提供一个清晰的蓝图

怎么创建model？

因为model不再是一个简单的类，因此不再需要"build the model"，相反的，我们开始创建services，然后实现Domain Objects和Mappers。

代码示例：

class Controller {
  public function handle(Recognitions $service) {
        $service = new Recognitions(
            new DataMapperFactory(),
            new DomainObjectFactory
            );  
        $service->authenticate($request->get('username'),
                                $reuqest->get('password'));
  }
}


namespace Service;

class Recognitions
{
    // -- snip --

    /* This is an EXAMPLE, not a production-level code.
       Do not copy-paste! */
    public function authenticate( $username, $password )
    {
        $account = $this->domainObjectFactory->build('User');
        $mapper  = $this->dataMapperFactory->build('User');

        $account->setUsername( $username );
        $mapper->fetch( $account );

        if ( $account->matchPassword($password) )
        {
            $state = $this->dataMapperFactory->build('Cookie');
        }
        else
        {
            $state = $this->dataMapperFactory->build('Session');
        }

        $state->store($account);

    }
    // -- snip --
}

可以看到在controller中，我们只需要通过service来访问我们的Model层。

View

在PHP中view可能就是一些模板，例如Laravel中的Blade，Symfony中的Twig，此处不具体展开了，有兴趣的可以自己Google。

Controller

controller里面的逻辑比较薄，主要是负责做参数的验证，然后调用各个service执行具体的逻辑。

Routing

现在的uri都比较简洁，典型的如下：

/users/view/1

或者是RESFful的URIS：

/users/1

像上面的第一个uri，我们很容易就知道该uri是映射了了UsersController的viewaction，参数是1。

除了这种按照框架既定的规则去创建控制器，创建方法，我们也允许用户自己去定义路由规则。

在Framework2中，这种映射方法是像下面这样的：

return [
    'router' => [
        'routes' => [
            'user' => [
                'type'          => 'Literal',
                'options'       => [
                    'route'    => '/users',
                    'defaults' => [
                        'controller' => 'AppControllerUsers',
                        'action'     => 'index',
                    ],
                ],
                'may_terminate' => true, 'child_routes' => [
                    'view' => [
                        'type'    => 'Segment',
                        'options' => [
                            'route'       => '/view/[:id]',
                            'defaults'    => [
                                'action' => 'view',
                            ],
                            'constraints' => [
                                'id' => '[0-9]+',
                            ],
                        ],
                    ],
                ],
            ],
        ],
    ],
];

上面的这种定义，给予了使用者最大的便捷，只要你去定义，你就可以使用。

而Laravel则是另一种风格：

Route::get( 'user/view/{id}', function ( $id ) {
    return 'Viewing User #' . $id;
} );

这种风格给我们提供了更好的体验。

MVC isn't Good Enough

MVC是一个好的开端，但是只有3层能够帮助我们组织代码，导致我们有任何东西都希望能够将其按到这3层中，我们尝试着将其按到model，view或者controller中。view我们一般不会有什么异议，因为view功能都规定的很明确，但是controller和model往往我们争论会比较大，业务的逻辑是放入控制器中呢还是model里面。社区对此很久之前采纳了“胖model，瘦controller”的方案。

Obese Models（胖胖的model）

“胖model，瘦controller”的方案一直都很好，直到model层变成数据库抽象和持久层，现在核心的业务逻辑也紧密的耦合到了数据源上。最终，model变为了胖model方案。但是这给我们带来的问题是：我们很难替换掉数据层，因为我们跟实际的数据库耦合很严重。

我们考虑一个场景，刚开始的时候，我们的应用直接从数据库中获取数据，但是随着应用规模的变大，我们决定应用不再直接操作数据库了，而是通过统一的web api来管理所有的数据操作，此时，由于我们将业务逻辑和数据的获取一起耦合在了model中，我们不得不重构我们的代码了。

我们在考虑另一个场景，此时我们也不是改变数据源，我们只是找到了一个更好的数据库抽象层，这个抽象层有更好的性能，此时仅仅因为需要替换到一个更好的数据库库，我们就必须要重写我们的model了。

以上我们所举的例子都违反了SRP（单一职责）原则。

一个好的，clean model应该是这样的子：

class User {
    public $id;
    public $alias;
    public $fullName;
    public $email;
}

至于我们怎么从数据库中的数据映射到User，怎么将User的更改持久化到数据库等等，这些问题我们会在后续的文章中介绍。

Model Layer vs Model Class vs Entities

以上举的问题都可以用我们上面介绍的model层来思考，MVC的中的Model不是我们简单意义上的一个class，而是一个layer，分为�Domain Objects，Data Mappers，Services，其中Domain Object有些地方也叫做Entity，Data Mappers又称为persistence layer，Service则是我们具体的一些领域逻辑。

More Layers for All of the Things

从简单的MVC三层架构中，我们为了解决model的关注点分离，我们将其分为了Entity，Persistence，于是我们就有了EPVC架构，但是所有的问题，我们不可能总是通过简单的增加层来解决，例如：一些展示层的数据和我们领域数据它就是不同的东西。

最后总结下：我们通过EPVC，将易变的数据库操作抽离了出来，将Entity这种不易变的作为系统的核心进行系统设计，根据系统核心要依赖抽象，稳定的，而不是易变的原则，我们重新组织了MVC模式。但是仅有MVC是不够的，我们还需要其他更好的方案，下面的文章将继续介绍更好的解决方案。

这是The Clean Architecture in PHP的第六篇，你的鼓励是我继续写下去的动力，期待我们共同进步。

参考文献

MVC是一个巨大的错误 MVC，MVP 和 MVVM 的图示 怎么组织model ACL How is Doctrine 2 different to Eloquent? Is ORM abstraction a pipe dream? database design TOP 5 PHP TEMPLATE ENGINES