Model以及数据库层

在合作的同事中,听到了一些误解的声音,一个是抱怨Yii框架的Model难用,因为Yii框架的Model从DB中取出数据后,就已经转换成了一个对象了,而不是PHP程序员所熟悉的Array,并且,没有提供相关参数直接取得Array数组。

思辨1:不知道别的框架到底是怎么处理这个部分的,因为MVC模式中,这个M指的正是Model,Yii框架的处理模式,我认为非常恰当,因为如果M只返回了一个Array,那么其实并没有真正的提供Model,而只是把操作DB的过程封装了起来,没有提供这个层次的一种抽象能力,最终还是需要在PHP语言这个层次上解决问题,等于是框架没有在M层提供恰当的抽象机制。

思辨2:Yii框架确实没有提供参数,可以控制直接返回Array,但是Yii框架的Model却保留了Array语法的便捷性,底层的CModel实现了IteratorAggregate, ArrayAccess两个接口,恰恰保留了按照Array语法操作Model的能力,这是何其贴心,按照我个人的风格,是断然不会提供这种东西的,因为这明显是为了照顾那些对面向对象编程非常不适应的程序员。如果非要一个真正的、纯粹的Array,Model还提供了getAttributes方法,可以将一个Model封装的数据,真正的转换成PHP的关联数组。如果,做到这样,仍要抱怨说我为了得到一个Array,非要做两步操作,那真的我要搞不懂了,到底是出于什么特殊的原因,你非要得到一个底层Array呢?(事实上,在我们公司的项目,到真的总是需要得到一个纯Array用于网络传输,这是因为公司的相关制度带来的复杂性,这个在一般的Web项目中,不会出现,作为框架本身,没有必要为了照顾特殊公司的特殊规定,而去增加什么特性,所以这算不上是Yii框架的设计缺失)

另一个常见的误解,就是关于Model的批量数据操作能力。

思辨1:就我个人看来,Model应该是对数据库的一个表的一行记录的一个抽象,而不是对一张表的抽象,所以,我们并没有通过Model获得表级的操作便利。所以,不能批量插入,批量保存,这很正常,这也符合Model的定位。

思辨2:Model在设计的时候,一定也是面临了艰难的抉择,并非不能提供批量数据的能力,而是那样的话,就破坏的Model层的语义,抽象层次就出现混乱,会进一步导致更深入的误解。

思辨3:Yii框架到底如何弥补这个不方便呢,就是开放了底层的DB接口,DBCommand,DBCommandBuilder,和DBCriteria。Command相当于对一条SQL语句的封装,可以看成是一种面向对象的SQL语句表达方式,CommandBuilder就是SQL语句组装器,Criteria是查询条件的抽象,这三者构成了强大的数据库层级的语义抽象,数据库能干什么,Yii框架就能干什么,而且更加语义化,更加安全。如果你仍旧不满意,干脆可以直接传个SQL语句进去,这个口子也开了。

思辨4:有了代表单行记录的Model,和底层DB的接口,事实上,数据层的接口已经趋于完备。但是我们发现Model里面仍然是提供了几个局限性很大的批量操作,updateAll,deleteAll,就我看来,就是一种无奈,一种妥协,一种折中处理。说它有局限性,是因为这种所谓批量,只是针对单一条件的批量操作,其实本质上是相当于某个名称空间下的全局函数了,看作是“桌面快捷方式”未尝不可,因为这几个批量接口可以完全被DB层的接口的语义取代。因此,我观察到,在实际项目代码中,这几个批量操作的利用率极低。

你可能感兴趣的:(YII学习日志)