The Clean Architecture in PHP 读书笔记(六)之你不知道的MVCMVC和其的局限性

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中各角色的区别:

角色

Model

�view

�controller

MVC

接收请求,并通知view

监听着model,当model发生变化的时候,改变(presentation)

接收到请求后,转交给model处理

Model2

接受请求,回传给controller

不具有行为,只是等待controller塞入数据到(template)

接收到请求后,转交给model处理,并将处理结果塞入view中

我们知道了我们讨论的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' => 'App\Controller\Users',
                        '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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

13 年的 Bug 调试经验总结

在《Learning From Your Bugs》一文中,我写了关于我是如何追踪我所遇到的一些最有趣的bug。最近,我回顾了我所有的194个条目(从13岁开始...

11220
来自专栏SDNLAB

P4和POF的对比

一、简介 软件定义网络(SDN)技术的发展已经历了多年,新技术层出不穷。OpenFlow作为其中的一个代表性协议,已经进化了多个版本,并被工业界和学术界广泛接受...

63830
来自专栏网络

ASLRay:一个可以绕过ASLR的工具

ASLR(Address Space Layout Randomization,即地址空间格局随机化)是指利用随机方式配置数据地址,一般现代系统中都加设这一机制...

286100
来自专栏JavaEdge

Java并发编程实战系列11之性能与可伸缩性Performance and Scalability

线程可以充分发挥系统的处理能力,提高资源利用率。同时现有的线程可以提升系统响应性。 但是在安全性与极限性能上,我们首先需要保证的是安全性。 11.1 对性能的...

37450
来自专栏大数据人工智能

ZStack--工作流引擎

在IaaS软件中的任务通常有很长的执行路径,一个错误可能发生在任意一个给定的步骤。为了保持系统的完整性,一个IaaS软件必须提供一套机制用于回滚先前的操作步骤。...

49640
来自专栏大愚Talk

为什么要用Redis

最近阅读了《Redis开发与运维》,非常不错。这里对书中的知识整理一下,方便自己回顾一下Redis的整个体系,来对相关知识点查漏补缺。

32520
来自专栏知识分享

曾经的UCOSii

我只是来分享自己的UCOS学习资料的,,顺便叨叨 ,自己是看着任哲的书一点一点学的,,, 自己大四的时候学的UCOSii,,但是好像学了之后,就只有一次真正使用...

47530
来自专栏web前端教室

继续电商网站的购物车

这一阶段的内容会比较枯燥,没办法啊。纯业务逻辑这块,写不出情趣来。有兴趣的就耐着性子看看,没耐性的可以等等看,改天写个有趣的内容之类的 我这个简单的购物车从功能...

43370
来自专栏Golang语言社区

13 年的 Bug 调试经验总结

在《Learning From Your Bugs》一文中,我写了关于我是如何追踪我所遇到的一些最有趣的bug。最近,我回顾了我所有的194个条目(从13岁开始...

35760
来自专栏前端架构与工程

Webpack中hash与chunkhash的区别,以及js与css的hash指纹解耦方案

文件的hash指纹通常作为前端静态资源实现增量更新的方案之一,Webpack是目前最流行的开源编译工具之一,其强大的功能也带来很多坑(当然,大部分麻烦其实都可以...

46470

扫码关注云+社区

领取腾讯云代金券