Yii项目开发总结 [ 2.0 版本 ]

学习Yii很久了，一直做的是小案例，自以为学的还不错。直到最近用Yii开发了一个非常简单的CMS，一路下来，磕磕绊绊，才知自己不足。加上最近正学习着偏架构方面的知识。特此总结一下。小白经验，大神轻拍，欢迎讨论。

本篇文章主要是将一些 MVC 代码组织的技巧，不会涉及详细编码。声明使用的模版是Yii高级模板。

痛苦的开发。

所有的php框架几乎都遵循MVC模式设计，网络各种教程、官方手册，也是一股脑的说着按着MVC组织代码。
先说说开发中我的悲惨历史。

大家都知道，在Yii中，一张表对应一个AR，再对应一个控制器。

在开发开始的时候确实是不错的。比如留言功能里面。我在common\models下生成了对应的AR类。然后在frontend和backend的控制器里导入了这个AR类，修改相应视图。然后根据需要对查询做了简单封装，即是在生成的AR类中写了一些方法，然后控制器调用。功能实现，代码逻辑也清晰。自觉棒棒哒。

然后就到痛苦的时候了。在设计文章和栏目的时候，我分了三张表：文章表，栏目表，文章内容表。在common\models生成三个AR类，后台、前台分别调用。由于创建文章时三张表都需要同时用到，以及插入、修改、删除的时候，需要用事务保证一致性。于是我只能就在文章的控制器里添加了一个又一个涉及数据库操作的方法。然后在前台显示的时候，又在对应的模型类里添加了一些方法，前台控制器又是一般修改。首页显示的控制器，映入了八个AR类。然后到最后，看着控制器里一个个AR查询的方法，AR类中又是一堆不同的查询方法，我彻底懵逼了。

好不容易实现完功能，自己都不敢看自己的代码了。

MVC中M的思考

开发完之后，痛定思痛。在大量阅读博客、书籍之下。获得以下经验，与君共享。

关于MVC中，首先声明的一点是设计要“胖Model痩Controller”，即Controller应该只有薄薄的一层。主要业务逻辑都在Model中。

视图层和控制层不用多谈，大家都知道。主要该谈谈的是模型层。

模型中前后台的组织

对于前后都要用到的模型，大家都会生成AR类到common\models，然后在frontend和backend的控制器里导入了这些AR类。但是，这不是一个好的习惯。前后台有着不同的应用逻辑。引用同一个AR类必然职责不清。正确的做法是在前后台的models文件夹里，新建不同的类，然后继承common\models中的AR类，做到模型分离。

举个例子。在common\models中有个Post.phpAR类，你应该在backend\models中新建一个Post.php然后继承common\models中的Post.php类。前台也是如此，做到引用分离。

业务逻辑层（service）

开发中必定涉及到多表关联。如果全部在控制器中引入模型类，写查询语句，代码组织就会非常糟糕，不利于维护管理，更正确的做法是。建立一个业务逻辑层（service）。

也就是做backend和frontend文件夹下建立一个services文件夹，保存我们的业务逻辑。比如我前面有三张表：文章表，栏目表，文章内容表，分别对应三个模型。当我需要保存一片文章时，同时涉及到三张表的操作。我就可以建立一个PostService.php，里面引入这三个AR类，然后建立一个SavePost()方法，在方法里同时对三张表做操作。这样，控制器里只需引入这个服务类，调用相应方法就行了。

读写分离。

实际的应用都是读多写少，因此，我们可以做到代码层面的读写分离。（详细的可以了解了解CQRS架构），方便分别优化。而且Yii中的AR虽然很方便，但是效率不高，太复杂的查询也是不好实现的。

这里Yii提供了一个简单高效的SQL查询。那就是DAO。
就是使用方式是这个的东西。

$post = Yii::$app->db->createCommand('SELECT * FROM post WHERE id=:id AND status=:status')
           ->bindValue(':id', $_GET['id'])
           ->bindValue(':status', 1)
           ->queryOne();

我们可以在services文件夹里建立只提供查询的文件，比如PostQuery.php文件提供对文章的查询

总结

第一次开发一个完整的东西，学习到了很多。最近打算对这个CMS进行重构。道路阻且长，加油！