太原PHP培训
达内太原php培训中心

0351-5608878

热门课程

PHP 读书笔记之你不知道的MVC(下)

  • 时间:2016-11-08
  • 发布:PHPer的进击之路
  • 来源:PHPer的进击之路

PHP 读书笔记之你不知道的MVC(下)

今天继续为大家带来php中很多的小秘密,这些小秘密将会对大家带来很长足的进步。

View

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

Controller

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

Routing

现在的uri都比较简洁,典型的如下:

/users/view/1

或者是RESFfulURIS

/users/1

像上面的第一个uri,我们很容易就知道该uri是映射了了UsersControllerviewaction,参数是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层中,我们尝试着将其按到modelview或者controller中。view我们一般不会有什么异议,因为view功能都规定的很明确,但是controllermodel往往我们争论会比较大,业务的逻辑是放入控制器中呢还是model里面。社区对此很久之前采纳了model,瘦controller”的方案。

Obese Models(胖胖的model)

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

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

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

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

一个好的,clean model应该是这样的子:

classUser{

public$id;

public$alias;

public$fullName;

public$email;

}

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

Model Layer vs Model Class vs Entities

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

More Layers for All of the Things

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

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

好了,今天就给大家讲这么多吧,喜欢我的内容可以关注或者分享(微信公众平台:tytedu)选择太原达内培训,不再孤军奋战,轻轻松松做IT高薪白领。太原达内培训带领有明确目标的学子迈向成功之路!

上一篇:PHP 读书笔记之你不知道的MVC(上)
下一篇:CmlPHP V2.7.1,快速稳定易维护的 PHP 框架

太原php培训资源站

太原PHP编程开发并发编程槽与坑

Php开发规划自己的路

太原php培训老生常谈php

选择城市和中心
贵州省

广西省

海南省