浅谈Zend Framework, CodeIgniter与Kohana

抛砖引玉，这三份框架 我都花了一定的时间精力去了解，根据项目的不同需求，我会选择不同的框架来进行开发。所以，如果你想知道哪个框架最好，本文没有答案，如果你想知道哪个框架最适合你现在要开发的项目，也许可以参考一下。

先简单的介绍一下我对三个框架的熟悉程度： CI (CodeIgniter) > K2 (Kohana) > ZF (Zend Framework)。CI我是从05/06年开始用的，最早开发的一电子商务系统还是用的1.3的版本。Kohana是从刚一发布后就开始用了，并且是 当初首批开发者之一，之后也时不时的会去递交bug。Zend Framework从还没发布起就开始关注了，发布后大失所望，就没去特别研究，直到上礼拜开始在新公司上班，我就提议用ZF来开发中大型的项目，所以这 几天几乎100%的时间都在弄ZF上。

下面我就来简单的聊聊各框架的优劣。一部分是客观事实，一部分是自己的经验和经历。

CI的优势

轻量

CI的轻量意味着开发者可以在短时间内迅速上手，迅速进行开发。我当初花了2个小时阅读了用户手册后就直接开始开发了，基本上也没遇到过什么大问题。就目 前论坛和群里的一些新手开发者们而言，好多人都是不仔细看用户手册，就问这问那，提问没有错，但是提问有提问的艺术。在国外的技术论坛上经常会看见人 说“RTFM”，意思就是“Read The Fxxxing Manual”——看手册！

文档健全

在开始用CI前，其实我是先接触的CakePHP 的。 因为当时Rails刚开始崭露锋芒，Cake则是紧随其后。最终我选择CI的原因很简单——CI的文档健全，而当时Cake的文档则是一塌糊涂。即便至今 日，CakePHP的文档还是不健全（特别是1.2 branch的）。当然，如果你是大牛，你直接可以去看API，但再怎么牛你还是得花时间花精力去研究API。健全的文档带来的好处是心照不宣的。

PHP4兼容

新手可能会纳闷，PHP5都出了那么多年头了，PHP6都呼之欲出了，还整PHP4干嘛。这个有些工作经验的开发者都了解——因为需要支持legacy server。部分客户的网站是PHP4的，没有条件升级（资金、时间等许多因素）到PHP5。CI是这三个框架中唯一支持PHP4的。并且由于 ExpressionEngine的广泛应用，短时间内CI是不会更新为PHP5 only的。

丰富的library

与CakePHP比较一下后就不难发现，CI提供了许多丰富的library，比如zip、上传、图片处理等。这些library的存在大大减低了开发的难度与周期，也减少了整合外部library的需求。

CI的劣势

过于轻量

框架提供了基本的MVC功能，但是“增值”功能除了一系列的library外，就所剩无几了。数据库处理方面也只有“伪ActiveRecord”，不适 合进行大型项目的维护（除非自己开发一套数据层）。当然，部分功能可以由第三方的library来弥补。比方说我现在如果用CI开发项目的话，首先就会去 下载Matchbox或HMVC library，让程序模块化。

开发缓慢

由于Ellislab的主打商业程序是ExpressionEngine，而EE和CI用的是两套codebase，所以CI的开发进度十分缓慢。EE 2.0将会与CI整合，到时候也许CI的开发进度会加快。但就目前而言，开发进度是十分缓慢的，tickets也处理的非常慢。我上一次递交的bug是几 个月以后才有developer来看的……

商业公司的自制开源 授权

虽然CI的授权是基于新BSD的，但毕竟是商业公司的定制的开源授权。对于授权比较敏感的公司而言，可能会敬而远之。

前途未卜

如果EllisLab的ExpressionEngine慢慢的被市场所淘汰的话，CI很可能就跟着一块儿沉默了。这也是为什么我新入公司后，对CI只字未提，直接推荐ZF。

官方library质量参差不齐

虽然CI提供了许多的功能性library，但很多时候你会发现这些library不够用。我曾经给image library递交的一个bug被鉴定为程序的feature。此bug在我之前也有人递交过了，只能说CI开发者对某些事物的看法比较“怪异”。

公司指向，非社区指向

由于CI是商业公司的产物（尽管最先只是公司老总自己业余时间的玩物），所以CI的走向必定是根据EllisLab的商业规划来走。开源社区的影响力极为有限。

K2的优势

CI的延续

Kohana原本诞生的原因便是CI对于开源社区的无视。bug没人管，feature request也没人看。最终一帮CI的用户自行组织，开始对CI进行bug修复和内容的添加。Kohana 1.x是对CI的直接扩充，向下兼容CI。而Kohana 2.0开始则是全新的codebase，不兼容CI。但是仍然与CI有着许多相同之处。

PHP5

K2由于没有legacy客户的顾虑，所以毅然而然的选择了PHP5 only。由此，理论上K2的性能应该略高于CI，并且整体框架更符合OOP理念。

高质量的代码

尽管CI的代码质量也是比较高的，但相较于K2而言，我还是不得不佩服K2开发者的天赋。欣赏K2的代码是一种享受。这个与“欣赏”某国内的CMS程序的代码，是截然不同的两种感受。

进阶功能

什么功能能被称作是进阶功能？这恐怕很难说清楚，根据个人的经验经历不同，看法也不同。但至少，K2提供了一套ORM，一套unit test——这都是CI所缺少的功能。

社区说了算

由于K2当初成立的理念就是开源社区自己的CI。所以，开源社区的影响力是极为高的。

更新快

用SVN经常co一下就知道，K2的更新是非常快的，这也是“真”开源社区的优势之一。递交bug的人多，开发者多，修复bug的周期也短。我曾经连续递交了几个bug，都是第二天就直接打入trunk了的。

K2的劣势

文档残缺

这个和CakePHP一个毛病。对于我而言，由于已经非常熟悉CI了，所以上手K2并不难。但是，如果是新手（PHP中等以下水平，不熟悉CI或其他MVC框架的），我不推荐使用Kohana。

社区小

K2的论坛人气很低。尽管开发者和高级用户（指经验丰富的用户）很多都活跃于IRC，但IRC毕竟只是聊天室，不方便技术的讨论与存档。这也是我后来淡出 Kohana开发团队的原因之一——Kohana开发团队的大部分成员都在美国，他们在IRC里聊的如日中天的时候，我这边是滚床睡觉的时间。

功能库不全

K2使用全新codebase的直接劣势之一，便是没法用CI的library了。部分library被移植到了K2上，但是绝大部分都是互不兼容的。如果要用其他功能，就必须去找第三方的库。

前途未卜

这点与CI一样。没有大型的企业和网站的支撑，很难说这个框架能存活多久。当初K1团队的leader由于工作原因，淡出后，K1项目就停滞了一段时间，直到后来K2的leader（原K1主力开发者之一）接管后，才又恢复了原本的开发进度。

框架成熟度

K2还处于开发初期，尽管2.0版本已经可以投入production了，但还是会发现API经常在更改。这点与开发者的年纪和经验相关。K2的leader只20出头，虽然技术上是个大牛，但项目管理方面的经验依我短暂的观测，还是比较缺乏的。

ZF的优势

正统王室血统

ZF是流着Zend的血的。可以确切地说，PHP不死，则ZF必活。不管ZF是好是坏，Zend是拥有众多合作企业的，这些企业开始运用ZF后，不仅仅将 会让ZF更上一层楼，而更会将PHP更上一层楼。前途一片光明。企业用户如果需要PHP框架的话，大部分都只有ZF这一个选择——技术是其次的，而商业背 景是首要的。

Component-based框架

尽管各组件中有部分是相互依赖的，但总体而言，ZF的自由度相当大。这点是为企业应用量身定制的。这也直接意味着ZF可以相对简单的被集成到其他框架中。

严格的项目管理机制

任何大的改动或更新，都需要经过一套严格的评估手段，从proposal开始，到community review，到zend review。如此这般，能保证任何大的改动都是经过仔细推敲的。

ZF的劣势

文档大，而不精

之前我一直以为ZF的文档是非常出色的——因为量多。直到亲身体验后，才发现并不是这么一回事儿。文档虽然看上去量大，但是不全不精。一半以上的时间我还是必须要通过google搜索方案。这点是十分遗憾的。

自由度高，但一定程度上是假象

ZF相对其他框架而言，的确自由度很高。但是，也有一些令人很恼火的“规矩”。比如类名：类名里不能自由的使用“_”（下划线），因为ZF会自动对类名进 行解释，比方说My_Super_Class这个类名，ZF便会去My/Super/Class.php里找。还有一些时候，类名中必须要有下划线，否则 某些功能不能用（查看ZF源码后确认过的，下划线的使用是写死的）。

不适合小型项目

Bootstrap的建立，以及其他一些设施的建立，都需要花一定的时间和精力。所花的精力与收获，对于小型项目而言，不成正比。CI与K2半小时内能完成的工作，在ZF上可能要花5、6个小时。

中规中矩

ZF由于讨好企业用户，所以一切都是那么的中规中矩，完全没有开发RoR程序时的激情。观赏RoR的视频时，很多时间都会感到“哇”，原来开发程序可以这么轻松这么有意思。而观赏ZF的视频时，则只会感到“哦”。

版本号虽高，基础功能不全

ZF在短短的时间内，就迅速的推出了1.0，乃至现在的1.5版本。版本号看上去很高，可是缺缺乏很多基础功能。比如Pagination（传闻1.6将 有可能接受proposal，通过 review并加入Zend_Pagination）。而对于企业开发而言，缺少一个功能强悍的ORM层。Zend_DB_Table的应用不够人性化。 飙版本号给人的感觉和数码相机厂商飙像素一样。

出错给出的信息不够全面

这点Rails和Kohana都做的相当的完善——两者均有非常详细的stack trace和其他相关的信息，帮助开发者debug。而ZF则只是输出一大堆exception内容，看着眼晕不说，还帮助不大……

 

以上只是个人的一些浅见，抛砖引玉而已。希望可以给一些新手们一点点参考的内容，方便大家根据自己的需求选择一个合适自己的框架。

 

http://blog.csdn.net/phphot/article/details/2606517