这篇文章是一个翻译，英文原文在 PHP frameworks revisited – CodeIgniter vs Zend，我的英文水平很一般，可能会有翻译不确切的地方(把握不大地方使用斜体进行了标志，并附带了英文原文)，请指正，并参看原文。 Emeric.Lee 2008.10.17
我们计划从头开始一个新项目，为此评估了一些PHP框架。我们的备选列表有CakePHP ， CodeIgniter ， Symfony和Zend 。 我们分别使用这4种框架编写了一个相同的小应用（一个简单的Wiki应用），希望我们能尽快选定一个最合适的。
声明：我会努力确保自己的客观性，虽然我是一个ColdeIginter的爱好者。我所工作的公司是Zend的合伙人（我们已经使用了Zend Platform 和 Zend Studio）。I can’t help factoring that in。
尽管一开始的计划是评估4个框架，但是这篇文章实际是CodeIgniter和Zend Framework的直接比较。在花费了几个小时研究了这4个框架后，我不得不把Symfony和CakePHP从名单中排除。理由如下：
- Learning curve 学习曲线
Symfony 和 CakePHP都有一个非常陡峭的学习曲线。CakePHP有严格的规则：数据表明此、文件位置、方法名和类名。Symfony使用 .yml 格式（需要学习，虽然它不是真的很难）来存储配置信息，并且大量的操作需要通过控制台(console)完成，创建数据表、数据模型和很多其它文件都需要使用命令行。 - Strict ORM: 严格的ORM
Symfony 和 CakePHP都有一个成熟的对象关系映射器(object-relational mappers | ORM) ，提供对数据的访问，但是这一特性很难被禁用，除非作出大量的努力。这些ORM有着严格的规则和约定，它们必须被遵循。与之相反，Zend Framework 和 CodeIgniter 在是否使用Models和如何使用Models上非常灵活的。使用Models是可选的，虽然它们都有数据映射器（data mappers），但没有这些应用一样可以进行（开发编写）。应用的数据操作将是极其密集和精细（intensive ）的，我们不愿意受到选择的限制。 - Flexibility: 灵活性
Zend Framework和CodeIgniter比其他两个框架更灵活。
最终对比
| CodeIgniter | Zend Framework | |
| Set Up 初始建立 |
CodeIgniter很容易初始化。 复制框架的所有文件到网络服务器，这是一个不错的开始。 它的文件夹也很小-大约2 .1兆。从开始建立，5分钟后，我就可以显示出默认主页。 | Zend Framework需要麻烦一些，它需要创建一个bootstrap文件，填写所有的初始化设置。比较之下，框架有点大-大约12.4MB。整个初始建立过程用来大约19分钟。 |
| 文档 | 文档的结构和组织相当好，但是不如Zend Framework详细。CodeIgniter有论坛和Wike，有很多用户提交的代码。 | Zend Framework有非常详细的文档，并且有很多示例。在我看来它的文档结构不如CodeIgniter，这可能是受到前面提到的细节和大量的可用的部件影响。ZF 也有一个Wiki，里面有少量的教程。 |
| 模板 | CodeIgniter包括一个模板分析器类，在我看来，它的作用是有限的，因为它不支持逻辑（例如，IF语句）。不管怎么说，CI建议在模板(view)中使用PHP标签。 | ZF 包含了一个布局类，用于给整个站点或者应用提供一个通用布局（或者多个布局）。它直接在模板中使用PHP标签，它也提供了一个抽象的View类，可以使用第三方模板库进行扩展。 |
| 组件 |
CI有很多库和帮助器来简化开发过程。尽管这些相比ZF还是显得少，但大体上，用法更简单(While it does have less of these than ZF, in the main, the usage of the CI variants is simpler)。 | ZF有巨量的类和组件。它们有着很好的文档但使用起来要比CI的稍微复杂一些。 |
| 数据访问 | CI有一个用于处理数据库连接的数据库类。这个类可以使用标准的SQL查询，使用标准的PHP方式进行创建、检索、更新和删除。 CI也提供了一个Active Record类，这是一个修改版的活动记录模式（Active Record Database Pattern）。这一模式可以让你使用更少的代码进行数据检索、插入和更新。某些情况下仅仅需要1到2行代码就可以进行一个数据操作。 除了简化，活动记录的一个主要好处是：它可以创建一个不依赖数据库的应用，因为查询语句是由不同的数据库适配器生成的。它还考虑了查询的安全性，系统会自动对变量进行escape。 |
Zend_Db 和它的相关类为ZF提供了一个简单SQL数据库接口。它接收标准SQL查询但是简化了获取查询结果的过程。它还包括了一个ORM，使用Table Data Gateway 和 Row Data Gateway。它们分别把数据表和数据行包装成对象，并且极大的提高了开发速度。 缺点是，和CI使用的修改版的active record pattern（没有广泛的使用对象）相比，有轻微的性能损失。 Zend_Db 还可以处理表关系。（Zend_Db can also model table relationships in PHP classes making database joins a breeze.） |
| 灵活性 | CI非常灵活，几乎所有的默认设置都可以修改。 | ZF其实一个类的简单集合， 所有的文件和目录可以被放置到任何位置，只要这些位置被加入到了bootstrap文件。 |
| 验证 | 在CI中数据验证是由一个验证类处理的。一些规则被定义并赋予验证对象（object），验证对象自动的验证从URL或者表单提交的数据。程序员可以决定如何处理这些获取。验证类还可以帮助自动的给指定字段设置错误信息。 | Zend_Validate 提供了一套常用的验证器。它还提供了一个简单的验证器连接机制，多个验证器可以按指定的顺序应用到单一数据上（datum ）。在ZF中，每个验证器都是一个不同的类，类被添加到数据（就像过滤器），而不是像CI一样，数据被传入类。In ZF, each validator is a separate class and the class is added to the data (like a filter) rather than the data being passed into the class like it is in CodeIgniter. |
| 表单 | CI中的Form Helper文件包含一些函数，用于帮助操作表单。它的作用是生成表单字段，但是书写HTML仍然是无法避免的。 | Zend_Form 简化了表单的创建和处理。它处理元素过滤、验证、escaping data、表单生成（rendering)。使用Zend_Form，ZF可以使用PHP完全的包装一个表单，包括标签、验证、错误信息。 |
| 性能 | CI大约有ZF的2倍性能 | ZF大约比CI慢一半 |
| 测试 | CI有一个单元测试类，但是它鼓励混合测试代码和真实代码，我不建议这样。也许可以使用第三方的扩展用于简单测试。A third-party extension for SimpleTest is available though。 和CI的类一起使用PHPUnit也是可以的。 |
ZF没有内置的测试类，但是它的核心类使用PHPUnit作为测试框架，这可以被扩展来包含所有的附加类 this can be extended to include any additional classes。在ZF中使用 SimpleTest 也是可行的。 |
| 国际化 | NO | YES |
| 授权 | BSD-style | New BSD |
综述
我对性能上差异非常惊讶（通过使用apachebench 衡量载入一个从数据库检索4条记录的主页）。我期望使用单纯PHP5的高效可以弥补ZF的额外大小。 I expected the efficiency of using PHP5 only features to make up for the extra size of the Zend framework.
Zend Framework的优势包括：
- “官方的PHP框架” 。
- 我工作的公司是Zend的“伙伴” 。
- 全功能布局和模板系统。
- 大量的类和组件。
- 极其灵活。
- 更先进的数据库库
- 更先进的验证库。
- 国际支持
CodeIgniter优势包括：
- 非常易于安装。
- 比Zend Framework更低的学习曲线
- 更易访问的文档
- 简明语法 – ZendF ramework的语法有些冗长
- 速度比ZF搞100 ％
在我来看没有任何明确的“赢家”，是的，我们还是没能作出选择。
译者注：原文作者在一开始就声明了自己是一个CI爱好者，因此我们可以基本肯定作者对CI理解肯定要比ZF深入，因此在初 次使用ZF构建测试应用是，我们可以设想作者对ZF优化和精细操控肯定不如对CI的，这应该会带来一些性能上差异。但是基于对ZF理解，我认为ZF的性能 应该是低于CI的，它的结构太严谨了，但应该不会有2倍的差距的！
这是2篇相关联的文章
这是英文原文后附带的一篇评论，似乎是由ZF的开发人员发，直接转过来了，懒得翻译了…
Great comparison, and I’m glad that you’re considering using ZF. A few points, however:
1) Set Up: We really don’t optimize for small size of the distribution archive. In fact, if you take a look in there, you’ll see about half of it is locale data in XML format. We plan to start building and releasing a ‘lean and mean’ distribution soon that I suspect will be no more than a few MB’s. But please keep in mind, if this is any measure of ‘bloat’, it is simply a reflection of how much disk space the framework takes up and possibly how many components we make available. Because all the components are loosely coupled, you can remove the components you’re not using to retrieve disk space as needed. Then again, I can’t remember the last time that I bothered to put any time in to paring down server-side software to save a few MB’s of disk space.
2) Documentation: How could we organize it better? I’m currently going through all the chapters to fix any spelling, grammar, technical, and style issues I see. I know that a few of the chapters are pretty rough English-wise since they were written by non-native speakers. Please send any feedback to wil@zend so I can keep it in mind while I’m doing this.
3) Database Access: Is there any noticeable performance penalty in using our more object-intensive approach when you take the heavy hit of a database query in to account? If so, let me know ASAP so I can profile and fix it.
4) Validation: I don’t understand what you mean by “the class is added to the data (like a filter) rather than the data being passed into the class like it is in CodeIgniter”. That description doesn’t match my understanding of Zend_Validate usage at all.
5) Performance: We get a lot of performance comparisons between ZF and other frameworks, but I have to say this is definitely one of the most generalized comparisons and sweeping conclusions I’ve ever seen between 2 complex sets of code.
You provide a basic description of your test case below, and honestly it doesn’t sound anything like a real world application. I hope you’re not taking the database calls themselves in to account, but I would *strongly* discourage making any kinds of conclusions based on such a simple comparison.
Performance benchmarks are hard. I’m not saying that ZF is slower or faster than CI in any definitive way; I don’t have the numbers from a sound experiment to back up such an assertion. But we do plan a full performance audit of ZF with comparisons against other major frameworks (CI may or may not be benchmarked) with full disclosure of methods. This will require about 2 developer months to finish with the direct help of our ZF architect and one PHP core developer. *That’s* how serious I am when I say it takes a lot to come up with conclusions about performance for complex pieces of software.
If you need some gauge before then, consider writing a small front-to-back part of your application using all the major features you expect to use in the final application on both frameworks and performance test it for major use cases. If you don’t have the time for that, then just let me mention now that ZF 1.6 and the quickly following 1.7 will both include significant performance enhancements.6) Testing: Matthew, our ZF architect, has just completed a controller unit test harness that make testing controllers a piece of cake using PHPUnit. He’s mocked sessions, request and response objects, and- well- you might want to just check it out in the incubator: http://framework.zend.com/code/browse/Standard_Incubator/library/Zend/Test/PHPUnit/
7) General: Fortunately, you don’t necessarily have to chose one or the other, anyways! ZF components will work just as well within CI. It’s used very commonly alongside all PHP frameworks out there.
In any case, best of luck with whatever framework(s) you’re using!
,Wil
