石头杨
石头杨 发表了说说推荐一个博客，http://oomusou.io/- 石头杨 发布了教程Yii 行为简单应用
AR模型虽然效率低一些，但是有更多的高级功能。比如事件，行为，事务等等。拿写操作来说，AR模型中提供beforeSave, afterSave这这两个方法，这两个方法会触发相应的事件，你可以在这些事件上绑定一些事件处理器完成对写流程的控制或者完成额外的一些操作，这是Yii2操作数据库最为高级的方式，也是最精华的优点之一。个人以为，牺牲点运行性能，增加开发和理解上的便利性是划算的。
不好意思，是我没有表述清楚。我说的是代码层面的读写分离。并不是全用 SQL 语句。
数据库操作就涉及增、删、改、查，其中增、删、改都是会对数据库的内容的状态造成改变，而查操作是不会对数据产生修改的。
针对这个特性，我们可以在代码层面做出读（即查）写（即增、删、改）分离。便于针对不同的优化。
我提出的是，写操作使用 AR 模型，读操作则直接用 SQL 语句。
原因有这么几点：
- 一般的应用中80%是读，20%是写，或者更高。AR 效率低，用来做读性能消耗太大。
- 使用 AR 做读的话，全部采用面向对象的方式，一些复杂的查询不宜实现。
- 其次使用 AR 做读，你并不了解最终生成的 SQL 是什么样的。检测到一些SQL语句执行过慢时，AR 中不好优化。
其实究根结底，最终还是为了性能和维护。
- 石头杨 2016-12-09 已签到连续签到1天，获得了5个金钱
写的不错！我也是刚刚学习，交流下经验。对于model层，我一般都是放在common中，但是为了防止混淆，我会建立表单模型，譬如：Post.php，我会让它对应一个PostForm.php（继承自Model），让它处理业务逻辑，Post.php仅仅处理简单的数据操作或者完全就是一个数据模型。如果，按照楼主的方法，虽然前后端代码分离的更加清晰，但是我想这样做代码是不是会有很多重复了。。毕竟，模型层的操作会有很多一样的。
嗯嗯，学习了，这个方法不错。关于前后端分别建一个 Model，继承 common 中的 model，也只是针对一些复杂的，需要较多业务操作的，简单的直接 common 中一个model 就行了。一切根据需求来就行了，不导致过度设计。
- 石头杨 发布了教程phpunit 测试入门
