比较三种php框架：Zend Framework, CodeIgniter与Kohana

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

CI的优势

轻量

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

文档健全

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

PHP4兼容

新手可能会纳闷，PHP5都出了那么多年头了，PHP6都呼之欲出了，还整PHP4干嘛。这个有些工作经验的开发者都了解――因为需要支持legacyserver。部分客户的网站是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的开发进度十分缓慢。EE2.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没人管，featurerequest也没人看。最终一帮CI的用户自行组织，开始对CI进行bug修复和内容的添加。Kohana1.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内容，看着眼晕不说，还帮助不大……


以上只是个人的一些浅见，抛砖引玉而已。希望可以给一些新手们一点点参考的内容，方便大家根据自己的需求选择一个合适自己的框架。 aleyn (2009-6-03 10:16:14)作者: 美丽人生
原文出处： http://www.phpchina.com/bbs/?fromuid=129367

不过对于 ZF 的未来，我不大看好。

PHP 最大的优势是快速开发能力，ZF 背离了 PHP 的这个能力，而去学习 Java/.NET 体系那种所谓的“严密性”，简直是丢了西瓜捡芝麻。

和 Zend.com 合作的各个公司，也是各有各打算。难道 IBM、MS、Sun、Oracle 等任何一个公司会希望 PHP 强大起来么？
恰恰相反，这些公司想的都是把 PHP 变成他们各自平台的一部分，并且把 PHP 开发者吸引过去用它们的平台。

就像 IBM、Sun 不可能让任何语言威胁到 Java 在企业应用领域的地位一样，MS 也不会让 PHP 威胁到 .NET 的战略使命。至于 Oracle，与 Zend.com 合作，只不过希望进一步与 MySQL 竞争而已。所以 Zend.com 的这些所谓合作伙伴，只不过一点点利益的相互需要。一旦 PHP 开始威胁到他们的核心利益，立马会遭到无情的打击。

RoR 的快速开发能力众所周知，但 RoR 也对 Java 在企业级领域的统治地位毫无威胁。所以我认为 PHP 的优势和发展方向就是快速开发能力，ZF 不走这个方向是没有前途的。 aleyn (2009-6-03 10:18:24)作者: smallipis 
原文出处： http://www.phpchina.com/bbs/?fromuid=129367

我原文“严密性”这个词是加了引号的，不过我也觉得这个词用的不恰，可能用“严谨”更合适一些。

我用“严密性”这个词的意思是 PHP 本就是一种很松散、很随意的脚本语言。如果非要像 Java 和 .NET 那样，把一切的一切都框在一些条条框框里面，既限制了开发人员的发挥，又降低了生产力。

当然，这种严密性不是没有好处。比如许多技术管理者都发现用 Java 的开发者即便基础知识不够扎实，但看着别人的代码照猫画虎，也可以写出可用的代码。而反观 PHP 开发者，如果没有足够扎实的基础知识，做出来的应用问题是非常多的。这就是 Java 被称为工业化语言的重要原因。

PHP 有很多自己的特性，比如弱类型、解释执行等等。所以要设计一个 PHP 的开发框架，就必须尽可能发挥 PHP 的这些特性。试想如果 RoR 是 Java 框架的克隆，而不去充分利用 Ruby 语言的动态特性，RoR 根本就不会流行起来。

所以，我想我的观点可以解释为“PHP 的框架就应该有 PHP 的特点”。



对于“七月十五”提出的三点，我想可以这样说：

1、最开始 PHP 是作为开发“即写即用”应用为目标设计的，所以 PHP 语言在语法上并不是很严谨，而函数库更是五花八门。虽然这为开发者带来了不少困扰，但也正是这种简单易学的语法和功能丰富的扩展造就了今天庞大的 PHP 社区。

如果今天 PHP 要去追求语言结构和开发框架上的“严谨”，那么必然会失去快速开发能力：同一件事情要做到严谨，需要付出的代价和“仅仅需要做到足够好”有很大的差别。比较完成同等功能 Java 和 PHP 需要的代码量就可以知道了。

所以 PHP 的不严谨是它的一个显著特点，也是优势。正是这种不严谨降低了门槛、提高了开发效率。当然，任何事情都要讲究平衡，所以既不能一味为了快速开发追求不严谨，也不能为了追求严谨而失去自身的特色。

请冷静思考一下，如果 PHP 变得和 Java 一样严谨时，PHP 还有存在的价值吗？



2、ZF 的自由度是一种深刻的假象。难道因为我给了超人一枚火箭，就能说我让超人获得了更高的自由度（不要忘了超人飞得比火箭快得多）？

PHP 本身就具有极大的自由度，任何 PHP 框架都只会降低自由度，而不会提高自由度。对于初级开发者，他们不可能深刻理解一个框架的设计思想和方方面面，那么对于他们来说，一个容易学习和理解的框架的自由度将远远高于一个难以学习和理解的框架。而对于更高层次的开发者，难道框架的限制能束缚他们的手脚？

所以只要不是太烂的 PHP 框架，自由度都不是问题！有问题的始终是使用者本身。



3、“ZF上手需要相当的功力和相对较长的时间” ―― 这就是 ZF 最失败的地方！

有什么功能是 ZF 可以实现，而其他框架不能实现的？
有什么开发模式是 ZF 可以体现，而其他框架不能体现的？

既然既不能比其他框架实现更炫的功能，又不能支持更酷的开发模式，那么为什么要花费更高的学习成本去学习 ZF？

对于大中型企业来说，需要严谨性的地方，Java/.NET 都是更好的选择，而需要快速开发能力的地方，ZF 有何突出之处？
对于小型企业来说，三五个人七八条枪，又有什么项目是非 ZF 不可？

没有出色的性能、没有与众不同的功能、没有独树一帜的开发模式、没有降低成本、没有提高效率，ZF 的价值何在？


技术是为市场服务的。大部分选择 ZF 的企业，看重的既不是快速开发能力、也不是高性能、更不是牛逼的功能。而更多的是的团队协作能力、稳定的发展和商业品牌。

可是 ZF 的团队协作能力相比其他框架真的就有飞跃？框架的稳定（包括代码的稳定性和 API 的稳定性）真的就比其他框架更好（不要告诉你没有为从 ZF 1.0 升级到 1.5 而大兴土木）？Zend.com的品牌真的就能为自己的企业创造价值？

请理性的看待问题！