Yii框架的MVC实践的问题

一眨眼,使用Yii框架已经有两年的历史了。今天,改代码改得郁闷,我来吐吐槽。

Yii框架的官方文档,其实介绍了关于最佳实践的问题。就是Controller里该写些什么,Model里该写些什么,View里该写些什么。但是实际情况到底是怎么一回事呢?

Model,这里应该写什么,按照原有的最佳实践,这里应该实现所有的业务逻辑的。这个毋庸置疑。但是,Yii框架干了很浑的一个事情,就是做了一个ActiveRecord的东西,然后,各种案例教学,一搞Model这个问题的时候,好像就在讲这个AR怎么个好法。然后Model莫名其妙就跟DB搞一起了。然后大家就习惯性的提到Model总想到DB,再然后,Model就成了一个DB接口一样的东西。注意到这里的心态转变没有,Model跟业务逻辑的关系被淡化了。事实上,像我这样的公司,都不允许在Web服务器上连接DB,必须透过中间件,结果Model就惨了,彻底沦为了访问中间件的接口封装层。然后到底该如何实现业务逻辑呢?实现到什么粒度算是实现了业务逻辑呢?这个根本没有给出一个指导。比如,创建用户这个业务。你可以在Model里实现一个addUser的方法,把所有事情都做了。你也可以实现一个addUser,checkExist,sendEmail,然后在Controller里 if ($m->checkExist() && $m->addUser()) { $m->sendEmail() },你看,这到底算不算把业务逻辑写在了Model里呢?前一种,addUser在内部做完所有的事情,后一种,实现了三个子操作,在Controller里组装。前一种,Controller里干净了,就一行代码,但是复用性极差,因为别的场景,比如从文件向空DB导入用户的时候,就没必要sendEmail和checkExist,就无法复用第一种的代码,第二种的相对细粒度的,就容易复用。不是都说代码复用么,blahblah……结果人们很有很强的动力用第二种。但是,检查存在性,然后写入存储,最后发邮件,这个事情到底是不是业务呢?所以,Model里实现粒度的指导,至关重要。结果根本没有任何指导。最后,Model的实现,被彻底原子化了,而且粒度切分,按照个人的习惯而定,有的粗,有的细,最后,Controller就很恐怖地容纳了巨量的业务逻辑。

Controller,这里该写什么,其实是最模糊的一个地方了,其实正确的用法,我一直这么理解的,就是应该用Model实现一切业务逻辑,Controller里,就应该选择合适的Model,执行业务逻辑,然后将结果传递给用render渲染出来的View。在实际使用中是什么样子呢?比如有一个公用的预判条件,本来这种应该写在Model里的,但是很多Action需要这个预判,但是又不一定需要那个Model,结果这个预判被写在了Controller里面。甚至更广泛的一些判断条件,被写在了所有Controller的基类里。再比如,用户身份这个问题,应该封装在User组件里的,但是实际上,那样做理解起来太困难,很多人都搞不懂这个组件结构是怎么回事,然后为了方便,干脆把身份写在了所有Controller的基类里面,然后把身份id赋值给了Controller的公共变量。这简直就是灾难。

再说说这个View,这个本来是最简单的部分了。结果呢?按照条件展示页面的某个部分,总要判断某个条件吧,这个条件怎么来?应该在Controller里,由Model来计算。但是如果这个条件很通用呢?结果这个就被放到了Controller的基类里面。然后在View里直接调用Controller的函数,这个就是大错特错的一个事情。等于View知道了Controller的结构。最关键是,这个判断条件,根本就是业务逻辑的一部分。最后一团糟的就是连View里也间接透过Controller融入了业务逻辑。

以上我说的每种错误,都有看似简单易行的正确做法,但是为什么大家都没有去遵守呢?当所有人都犯错的时候,是不是该考虑一下,到底什么地方有问题呢?

2 Comments


  1. M 层里面不是数据层, 负责与数据库交互. C 层才是业务逻辑聚集的地方.


    1. 我还是认为M应该是封装业务逻辑的地方。比如我自己用到的,业务系统和开放平台两个场景,要做同一个业务,就二了,只能在开放平台的Controller里,拷贝一遍业务的Controller了。这太丑陋。

Comments are closed.