CodeIgniter缺陷探讨

bardo

凭心而论，CodeIgniter是我目前见到的最为优秀的开发框架之一。但是，优秀并不代表完美。
现就本人发现的一些缺陷，与大家共同讨论：
一、数据库驱动部分的缺陷。
CodeIgniter采用的是动态继承，从而实现了对多数据库的支持。这种方式可以说，比工厂方式要先进得多。
但是，我认为，CodeIgniter的动态继承用反了！
试想一下，如果把驱动作为父类，而CI_DB_driver作为子类，结果会如何？
那么，CI_DB_driver中就可以重写数据库查询，重写获取记录，那可就可以实现对数据CACHE的自动管理与使用。
可是现在，要使用CACHE却只有父类中的query函数，CodeIgniter在帮助中说明，CACHE不支持num_row,不支持num_fields，这不得不说是一大败笔！

二、对某些LIBARAY类的看法。
优秀代码本身目的是易于维护，易于扩展，但是CodeIgniter中的一些类，实在不敢恭维，现举两个例子。
第一是图象处理类，其中使用了三套图象驱动，但却将这三套的代码写在一个类中。第二是EMAIL类，做法与是这样。
试想，假如用户只用gd，单凭这一点，用户就需要加载所有的代码，资源开销不论，如果确有意外，要修改，或确有需求要改进，那么，只需要GD的，同样还需要对其它驱动的代码一一过目。这是快速开发，还是浪费用户时间？
试想，一个代码行如此多的类，是易于维护，还是难以维护？

（未完待续）

bardo

补充：动态继承用反了，则每个驱动中的每个类都要继承一个实际不存在的中间类。这不仅不利于单一类测试，同时，如果使用单一类测试，完成后，还不能忘了加上那个 extends CI_DB.否则,驱动则无法运行.并且,这也必须要明确写到文档中的,注明,开发CI数据库驱动,就必须要这么做.
试想一下,如果反过来呢?

zmh

太高深了，看不懂

Hex

好文章！欢迎大家踊跃讨论！

zshtom

对于三套处理图片的类 写在一个里的问题 可以参考 zf 的 cache部分  zf 的cache 部分就是按照 memcache file apc 等不同后端进行的处理 每个 后端的处理都是单独的类 实现相同的接口就可以了 前边核心类进行 封装

shipfriend

原帖由 Hex 于 2008-6-19 10:38 发表
好文章！欢迎大家踊跃讨论！

Hex，你小子就会说这一句，

bardo

三、再谈数据库的cache
数据库的cache，在更新查询后，删除所有的cache文件，这表面上看是没有问题，但是，读取文件时是加锁的。也正因为这一点，文件可能删除不了。然而，cache却没有设置有效期，这就导致了前端显示的数据可能不真实的问题。假如添加了有效期，在读取时，如果发现过期，则立即删除，这样，就是删除不了，那也不读取，这样，也是从数据中查询的新的。这就维护了数据的真实性。可惜的是，CI并没有考虑到这一点。

Hex

原帖由 shipfriend 于 2008-6-19 10:49 发表


Hex，你小子就会说这一句，

呵呵，别水了这贴！水平有限只能听大家的了～～

Hex

数据库的 cahce 我还没用过；数据库类我们也可以自己派生一个，重新实现他。

bardo

四、数据库类的扩展
懂一点设计模式的人都清楚，动态继承的类不再可以通过继承来进一步扩展。CI给用户提供了一个名为 call_function 函数，让用户扩展。
这种做法，对于初学者而言，或许可以大受欢迎。
但是，这种做法，实际上有很多不雅之处。
第一，扩展函数写在哪里？势必写在全局的helper函数中。
第二，扩展函数如何与数据库类交互？势必要在参数中把当前实例传入。

这种破坏封装的方式，还不如在文档中加上一个扩展实例，新建一个db_ext的类，代理DB类，同时，加上扩展函数。这样在使用时，就没有必要再弄什么函数名与DB对象做为参数了。

这种做法，不仅维护了程序良好的结构。同时，也提升了使用者的水平。但CI并没有这样做，使用这一函数的目的，或许可能是为了迎合初学者吧。但，KOHANA更注重这些，所以，HELPER函数也放到静态类中。这一点CI是值得借鉴的。

五、关于base类
我不明白，CI的base类为什么要针对不同的PHP版本写出不同的代码。其实，网上到处都是PHP4与PHP5中均能运行的单件模式代码。同时，还有更让人不解的，既然BASE实例可以用getinstance得到，为什么还要放到全局中。这种做法，实在让人难以相信，CI代码竟究有多大的可信度（如同cache一样，高要求时，数据一定会不真实的。）。纵有一万个理由，既然单个模式有版本兼容的代码，那么，就应当用上。但是，CI没有这么做。这在某种程度上大大影响了CI的形象。