


太原PHP培训
达内太原php培训中心
0351-5608878
今天继续为大家带来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则是我们具体的一些领域逻辑。
More Layers for All of the Things
从简单的MVC三层架构中,我们为了解决model的关注点分离,我们将其分为了Entity,Persistence,于是我们就有了EPVC架构,但是所有的问题,我们不可能总是通过简单的增加层来解决,例如:一些展示层的数据和我们领域数据它就是不同的东西。
最后总结下:我们通过EPVC,将易变的数据库操作抽离了出来,将Entity这种不易变的作为系统的核心进行系统设计,根据系统核心要依赖抽象,稳定的,而不是易变的原则,我们重新组织了MVC模式。但是仅有MVC是不够的,我们还需要其他更好的方案,下面的文章将继续介绍更好的解决方案。
好了,今天就给大家讲这么多吧,喜欢我的内容可以关注或者分享(微信公众平台:tytedu)选择太原达内培训,不再孤军奋战,轻轻松松做IT高薪白领。太原达内培训带领有明确目标的学子迈向成功之路!