作者分享了在使用ZendFramework进行Zendext工作时的个人体会，包括select对象的问题、性能问题以及数据层缓存接口的缺失。文章指出ZendFramework在数据库操作、性能优化和分层设计方面存在一些不足之处，并提出了一些改进建议。
因为最近一直在做zend ext的工作,因此花了不少时间读了zend framework的代码,也比较深入地在使用这个东西.下面有些小小的个人体会.
首先是select对象的一些小问题.select中有很多组语句的函数,但这些函数却不会判断是否传入是空字符串,导致输出变成两个单引号,这就要求开发人员在自己的函数里判断,这点不是太灵活.
接下来select的毛病是不支持外连接,实际上这个有些让我意外,意外的原因是居然不能支持,而从目前zend的机制来看它对于这个的支持是非常良好的,因为它已经加入了lazy概念也就是在1:n中常使用的一种性能优化模式,也是外连接支持的一个必备因素,这点很有点问题.但是当你仔细看看你会发现这个东西是一个半成品.实际上要做到无限联级的首要就是,必须把数据表映射成代码中的数据对象,虽然在php中没有pojo这个概念,但实际上你可以理解一个具有数据表所有功能的对象为数据表实体(entity bean).但zend目前的db构架显然还不是太完全,它给我的感觉更多的是把db作为了一个颗粒,也就是数据库或者叫做数据连接,这个颗粒度的分层我认为是有问题的.当然你完全可以封装上去,但是这意味着我们需要抛起zend的很多东西,也许这就是zend framework本身开放性带来的弊端.我说过,zf是一个本身完全oo但是可以让开发者完全不用懂oo也能写出好的php分层结构的东西,这就注定了它会具有很多弊端.
另外我发现zend的fetchrow有性能问题,虽然他返回第一个结果集,但实际上他没有对数据库查询做优化,也就是说当你传入一个select * from user 那么在zend里用fetchall和fetcherow性能本身差别不大,而理想的做法是在前面的语句中加入limit 1这样才会对性能有本质提高,否则这个方法的存在意义就不大了.
另外在数据层它没有预留cache接口,实际上大量的实践证明要提高php低下的io能力只能用缓存技术,否则任何一种主流语言的数据库连接性能都可以秒杀php.而cache接口没有预留意味着我们又要很费劲地在外面包上一层,这也是我在我的zend ext中所干的活.
首先是select对象的一些小问题.select中有很多组语句的函数,但这些函数却不会判断是否传入是空字符串,导致输出变成两个单引号,这就要求开发人员在自己的函数里判断,这点不是太灵活.
接下来select的毛病是不支持外连接,实际上这个有些让我意外,意外的原因是居然不能支持,而从目前zend的机制来看它对于这个的支持是非常良好的,因为它已经加入了lazy概念也就是在1:n中常使用的一种性能优化模式,也是外连接支持的一个必备因素,这点很有点问题.但是当你仔细看看你会发现这个东西是一个半成品.实际上要做到无限联级的首要就是,必须把数据表映射成代码中的数据对象,虽然在php中没有pojo这个概念,但实际上你可以理解一个具有数据表所有功能的对象为数据表实体(entity bean).但zend目前的db构架显然还不是太完全,它给我的感觉更多的是把db作为了一个颗粒,也就是数据库或者叫做数据连接,这个颗粒度的分层我认为是有问题的.当然你完全可以封装上去,但是这意味着我们需要抛起zend的很多东西,也许这就是zend framework本身开放性带来的弊端.我说过,zf是一个本身完全oo但是可以让开发者完全不用懂oo也能写出好的php分层结构的东西,这就注定了它会具有很多弊端.
另外我发现zend的fetchrow有性能问题,虽然他返回第一个结果集,但实际上他没有对数据库查询做优化,也就是说当你传入一个select * from user 那么在zend里用fetchall和fetcherow性能本身差别不大,而理想的做法是在前面的语句中加入limit 1这样才会对性能有本质提高,否则这个方法的存在意义就不大了.
另外在数据层它没有预留cache接口,实际上大量的实践证明要提高php低下的io能力只能用缓存技术,否则任何一种主流语言的数据库连接性能都可以秒杀php.而cache接口没有预留意味着我们又要很费劲地在外面包上一层,这也是我在我的zend ext中所干的活.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
