作者:LAMP小白 点击:1830 发布日期:2013-02-17 00:10:00 返回列表
MIOPHP之前是采用的THINKPHP的父子model关系,即由具体的SQL执行类继承SQL生成类实现不同的数据库操作方式,这种做法也是目前的主流,不过在1.0中我几乎阉割掉了model所有的SQL生成功能,在实际编码中,这样也许会稍显麻烦,因为你需要写出一整条SQL语句,而不是那种无脑的model('user')->S()的语句
但是我还是认为这样才是model应该具有的特性,那么就简单分析分析这样做的优劣吧
结构和性能
较之父子model,采用单model实现数据库操作首先在性能和结构上会有较大的优势,一个SQL操作,放到一大堆方法里面去跑一圈和直接运行在性能上差的不是一点两点,当然目前服务器的CPU是富余的,但并不代表我们就可以肆意的浪费他
其次,可以使用全部的SQL语句,试问有哪个model能把全部SQL语句都写成自定义方法?当然也许会考虑到并发优化,即单表查询然后通过使用PHP消耗CPU进行重组,但是这也是分情况的,如果是一个大并发程序,那么从数据模型上就会进行很多优化,如果只是一个小程序,干嘛不用更简洁的功能?
学习成本
采取方便的父子model,首先你得学会使用它,虽然这并不费事,SELECTG = S(),UPDATE = U(), INSERT = I(), DELETE = D()随便是谁照着手册看看就会用,但为什么我反对这样做呢?不仅仅是model,其他方法也一样,一个长期使用这种无脑SQL的程序员,他可能早就忘记真正的SQL怎么写了,更谈不上优化和创意了,虽然这样可以快速无错的开发,但一个人的思维被禁锢在这样无脑的方法中大脑早晚都会锈死,至少我不想成为永远只会抄袭别人代码和思维的码农,这也是目前国内的一种风气吧
而采取单model,你在平时也可以接触到原生态的SQL,也就是说你会写SQL就能马上用,也许你会想,如果想原生态那干嘛还用框架呢?我理解的框架并不是让程序员无限偷懒或者跨级干活的工具,而是一个帮你管理琐事的助手,在缓存和资源管理这些宏观的构架上面你可以让他来做,但在这些提升自身能力和程序性能的地方你就不应该使用它
通用性
之所以我选择PHP的PDO而不是MYSQL目的就是为了扩展,这样牺牲掉了一些早期的PHP兼容,也需要服务器开启PDO,但是在这虚拟主机都支持的环境下,有多少服务器不支持PDO呢?如果你还在玩PHP4那么当我没说,就像讨论IE6一样
阉割了这么多,model现在在干什么?
首先,model需要管理资源,这个功能我是通过_resoruce实现的,这与之前的_resource比又有了进步,之前是将new出的资源,根据表名保存在一个数组中,虽然父级model强制要求子model实现切换表的方法,但是_recourse并没有实现真正的model单例设计模式,他仅仅实现了表的单例设计模式
在涉及多表操作时,一个实例化model与数个实例化model的差距是明显的
其次,model要负责对结果的缓存
在query方法中加入了缓存,在查询时会首先检查memcache中的哈希,如果有60秒内的结果则直接读取缓存,没有再去找数据库
然后,model提供了对结果集的遍历和整理,方便我们进一步操作结果
URI返回一维数组或字符串
S()返回多维数组或一维数组
其他操作返回影响的行数或主键值
最后,model还需要包含健壮的错误检测功能
如果一条SQL出错,直接让他死掉或只打出一行SQL ERR是对框架用户的不负责
model需要暂存上一条SQL,影响的行数,并加入出错检测,出错时最好的办法是打出SQL语句和报错信息,err->fate就是干这事的玩意,这样程序员才能在不修改model代码的情况下快速找到错误,当然在生产环境中我们需要一个常量来管理它,让他显示一个友好的出错界面
缺点:
啊,不能无脑敲S()了,分页查询也不能无脑敲page(10)了,每条SQL所花费10~20秒
上一篇:apply和call 下一篇:快递查询API