热门课程:

太原PHP培训 > 达内新闻

PHP 读书笔记之你不知道的MVC（下）

时间：2016-11-08 11:27
发布：PHPer的进击之路
来源：PHPer的进击之路
分享到：

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

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应该是这样的子：

classUser{

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则是我们具体的一些领域逻辑。