提问人： 提问时间：3/12/2010 最后编辑：7 revs, 3 users 100%Pekka 웃 更新时间：8/4/2011 访问量：1482
对 Zend Framework 的承诺 - 有什么反对的论据吗？[关闭]
Commitment to Zend Framework - any arguments against? [closed]
问：
我正在翻新一个大型CMS，我已经工作了很多年了。产品本身很棒，但一些组件，例如数据库和翻译类，需要紧急更换 - 部分部件早在 2002 年就自制了，随着时间的推移变得有点混乱，并且可能难以通过安全审计。
因此，我一直在密切关注一些框架（或者更准确地说，是组件库，因为我不打算改变 CMS 的基本结构），并最终最喜欢 Zend 框架。他们提供了一个可靠的 MVC 模型，但不会强迫你进入它，他们提供了许多专业组件，这些组件显然受到了很多关注（你知道俄语中有多个复数形式，你不能使用简单的开关来翻译它们吗？我没有，但Zend_Translate能应付。只是为了说明图书馆似乎已经构建了这样的程度。($number == 0) or ($number > 1)
我现在真的处于不归路，开始用 Zend 制造的组件替换系统的关键组件。我真的没有第二个想法 - 我当然不想煽动一场火焰战争 - 但在继续之前，我想退后一步，看看是否有任何反对将大型系统与Zend Framework紧密捆绑在一起的东西。
我喜欢 Zend 的地方：
- 据我所知，非常高质量的代码
- 文档非常完善，至少在介绍事物如何工作方面（尚未使用详细的 API 文档）
- 由一家有兴趣看到该框架繁荣的公司提供支持
- 在社区中广受好评，拥有相当的用户群
- 采用我喜欢的编码标准
- 附带一整套单元测试
- 在我看来，在现代、专业的PHP开发方面，这是一个正确的选择，或者至少是正确的选择之一。
我一直在考虑将 ZF 的功能封装和抽象到自己的类中，以便能够更轻松地切换框架，但得出的结论是这不是一个好主意，因为：
- 这将是一个不必要的抽象级别
- 它可能会降低性能
- 使用框架的一大优势 - 存在一个熟悉其组件的开发人员基础 - 将被部分抵消
因此，对采埃孚的承诺将是深厚的。因此，我的问题：
有什么实质性的反对承诺 Zend 框架吗？
你对 Zend Inc. 在 2011 年走向邪恶并使其成为闭源库的计划有内幕消息吗？Zend Inc. 是由想要接管地球的邪恶吸血鬼经营的吸血鬼经营的吗？（在评论中确定 Zend 实际上是由吸血鬼经营的。当您将所有项目过渡到代码库时，您开始注意到代码库中是否存在概念缺陷？质量代码的出现是一种错觉吗？代码是否看起来不错，但在我的四核工作站以下的任何设备上运行都非常慢？
接受答案
非常感谢大家的详细反馈。我希望我能设置一个赏金，并在所有回答者之间平均分配。
在众多赞成采埃孚的意见中，有一个非常有根据的反对意见。我非常认真地对待这一点，并仔细研究了替代品，主要是 Yii 和 Kohana。从这种比较中，以及通过阅读有关采埃孚和竞争产品的更多意见，我可以看到，与更简约的框架相比，Zend 在某些领域可以被视为臃肿。（我还可以看到，这种“膨胀”大多是有充分的理由提供最大的灵活性。但是，无论您是想要最大的灵活性并处理随之而来的复杂性，还是想要具有明确指导方针的更简单的方法，这个问题都是有效的。
无论如何，我会为手头的项目选择 Zend，因为我对框架的主要用途是作为组件库。我不想采用 Zend 的 MVC 模型，我只需要高质量的组件进行国际化、会话处理等。因为我正在构建一个可再发行的产品，所以 Zend 的灵活性（例如支持五种不同的字典格式）对我来说是受欢迎的。此外，据我所知，采埃孚似乎是唯一允许我想要的自由度的框架（没有强制使用模式、文件结构......），没有其他框架提供这一点。
对于未来的项目，如果我想利用实际的 MVC 功能，并完全服从框架在应用程序构建、命名、样式和过程方面的约定，但是，我可能不一定会选择 Zend，而是选择更简约的框架，比如 Yii 或 Kohana。
答：
6赞
Pascal MARTIN
3/12/2010
#1
我对采埃孚没有任何反对意见——恰恰相反;当然，我还没有使用过所有组件（不确定是否有人使用过），但我在浏览源代码时从未见过任何看起来“糟糕”的东西。
在开始一个新项目时，我通常会自己选择Zend Framework，实际上，如果我是必须选择的人......
我至少想将一个论点添加到您的列表中：
- Zend Framework 可以与其他组件集成：您谈到了在应用程序中使用 ZF 的组件，但没有谈论相反的内容。
- 一个很好的例子是 Doctrine（Symfony 的默认 ORM），它可以很容易地与 ZF 一起使用——在我看来，它比 要好得多！
Zend_Db
- 一个很好的例子是 Doctrine（Symfony 的默认 ORM），它可以很容易地与 ZF 一起使用——在我看来，它比 要好得多！
除此之外，我不得不说，我同意你的每一个观点。
关于将 ZF 类封装到您自己的类中：是的，您可以这样做（我有时会这样做），但我不建议对所有事情都这样做：在大多数情况下，它可能没有必要。
关于未来：
- Zend Framework 是在 BSD 许可证下发布的，这意味着现有的东西不能是闭源的。
- 无论如何，关闭它就意味着它的终结——在PHP社区的背景下，这将是一个愚蠢的举动
- ZF 2.0 的工作才刚刚开始（顺便说一句，需要 PHP 5.3）
- 也许，根据您的申请时间表，它可能会很有趣？
- 至少如果你不需要在至少几个月之前开始开发......
评论
0赞
Pekka
3/12/2010
干杯@Pascal，特别是有关未来版本的信息。我需要快速开始，并且在可预见的未来需要支持 < 5.3，所以我现在必须坚持使用 1.x。格林威治标准时间午夜后将+1，票数不:)
0赞
Pascal MARTIN
3/12/2010
不客气：-） ;;关于采埃孚2.0，可以看看 framework.zend.com/wiki/display/ZFDEV2/......;您可以订阅contributors@邮件列表（参见 framework.zend.com/wiki/display/ZFDEV/... ） ;;;不过，快速入门和 PHP 5.2 还可以;;;不用担心赞成票：我已经达到了今天的代表上限^^
0赞
Stann
4/15/2011
有没有人更喜欢原始查询而不是 ORM 的查询（我愿意）？
15赞
clyfe
3/12/2010
#2
Zend Framework 是最佳选择。最好的框架 API、可读代码、语言约定、好的文档、社区、支持等等
我不喜欢它（主观的，人们会为此投反对票）是：
Zend_Form，有它的用途，但总的来说太突兀了，我只想构建我的 HTML 而不是对抗 API 和装饰器。Zend_Db_Table，强大，但它需要大量的工作才能实现你的目标，而 Rails 教会了我懒惰。不，我不想为模型编写 3 个类，一个用于表，一个用于行集，一个用于行，然后将它们相互绑定，依此类推。我可能需要表数据网关，但现在我真的想将此数据与快速活动记录连接起来。- 没有活动记录。随着 php 5.3 中后期静态绑定的出现，这可能会改变......
我非常努力地使用这两个几个月，直到我终于拥有它。
我通过（Ruby on Rails 的想法）克服了它们
- 使用普通视图帮助程序而不是Zend_Form，如下所示：
echo $this->formText('email', '[email protected]', array('size' => 32)); - 拥有自己的 Active Record like 模型 （ http://www.phpactiverecord.org )
- 验证和筛选模型
- 对于非常极端的极端情况，人们可以回退到 Zend_Form + Zend_Db_Table，尽管我从不觉得有必要。
编辑
有一些新孩子值得一试，比如 Laravel
采埃孚真正胜过其他框架的一件事是路由器、控制器和视图、约定、干净可读的代码、流程。
评论
0赞
Pekka
3/12/2010
为您的输入欢呼。顺便说一句，我同意你对这两个组件的看法。事实上，你不必全部使用它们并符合上层结构，这是我最喜欢采埃孚的地方。当我再次投票时，将 +1。
4赞
David Snabel-Caunt
3/12/2010
如果有一个组件我会捍卫到死，那就是Zend_Form！过滤、填充、验证、复合元素和装饰器是管理自己的艰巨任务。虽然装饰有点棘手，但有一些很棒的教程。
3赞
clyfe
3/12/2010
是装饰杀死了它！我不想与apis战斗，我只想构建我的html！看看rails的做法，我敢打赌你会重新考虑的。
0赞
Wil Moore III
10/13/2010
@David：我不得不对你的评论投赞成票。我同意。有些模式很复杂，但从长远来看非常值得付出努力。Zend_Form碰巧雇用了其中之一（装饰器）。
1赞
Sonny
11/16/2010
我为我的装饰器使用并创建了视图脚本。一路上有一些问题，但现在我喜欢制作表格。Zend_Form
4赞
Bryan M.
3/12/2010
#3
我们已经与采埃孚合作开发了将近一年的时间，我真的对它没有任何疑虑。有一点学习曲线，但一旦我理解了它，我就意识到这个框架到底有多好。
与其他框架相比，有些人可能会指出缺少模型库是一个缺点。实际上，我更喜欢不被告知该使用什么，而且将 Doctrine 与 ZF 集成是无摩擦的。如果你正在用 PHP 5.3 进行开发，并且想要一个 ORM，我强烈推荐 Doctrine 2（注意：它仍处于 alpha 测试阶段）。
另一件好事是能够挑选你想要或不想要的东西。我不是Zend_Form的忠实粉丝，但如果我不想，我就不必使用它。此外，还有一个结构非常松散的插件架构，可以让您轻松地将自己的库挂接到框架中。
所以，我是它的忠实粉丝。
3赞
Sebastian
3/12/2010
#4
我在 Zend Framework 中缺少的一件事是合适的 OR 映射器。Zend_DB还可以，但也有一些缺点，尤其是在处理大型数据库（许多表）时，它会变得非常麻烦。但是有几个 OR 映射器可以集成（例如 zend-framework-orm 或 Pascal MARTIN 提到的 Doctrine）。
但是，是的，Zend非常出色，非常强大，我觉得在某些方面，它在界面和功能方面是PHP实际上应该/应该的。
除了显而易见的之外，我特别喜欢的是 Dojo 对富客户端应用程序的支持和对 SOAP 的支持。
评论
0赞
David Snabel-Caunt
3/12/2010
这可能是最常见的客观批评，即没有ORM。您可以将 Doctrine 与 ZF 一起使用，并且即将与 Doctrine 1 集成（希望在 1.11 中），而 Doctrine 2 将与 ZF2.0 一起使用
9赞
pestaa
#5
除非你期待一个拥有 20+ 开发人员的庞大项目，否则如果我是你，我会做任何事情，包括牺牲一只胳膊和/或一条腿来避免 Zend Framework。
- 您发现的不错选项可能看起来很方便 - 以至于您发现其他 1k+ 设置看起来只是在库中浪费时间和开发人员的努力。您很快就会发现自己置身于自定义海洋的中间，被设置、界面和抽象类所淹没。
- 文档不仅详细，而且非常冗长和复杂（类似于库本身）。我希望第三部分课程可以帮助我，而不是妨碍我。
- 对我来说，最重要的因素显然是开发速度。如果你周围没有一堆大学，Zend Framework 应该认真考虑是否要放弃。
- 有太多人在 Zend issue tracker 中许愿，有太多的人在实现代码。到目前为止，我还没有看到这数百万行字背后有任何严肃的愿景。
我的两分钱实际上归结为一点：尽管（或者更确切地说，因为？）它得到了PHP公司的支持，但对于个人使用和中小型项目来说，它太臃肿了。
我的团队目前正在使用Yii进行一个中型项目。它也不完美，但与老大哥相比，它更实用，对开发人员更友好。
评论
1赞
Pekka
3/12/2010
感谢您提出严肃的、有充分论据的意见。我正在做的项目 - 尽管目前只有我维护 - 旨在成为大项目，并且有一天会由许多人开发（尽管可能永远不会 20+）。不过，你的批评是有道理的，虽然我非常倾向于采埃孚，也是因为它在开发者中的受欢迎程度（这一点在这里得到了很好的证实），但我会再仔细看看 yii 是否不能更好地满足我目前的目标。（目前没有投票，稍后将+1）
1赞
David Snabel-Caunt
3/12/2010
披露：我是采埃孚的忠实粉丝，可能有偏见。那么现在。配置：这是一个公平的观点，配置一些组件，尤其是 Bootstrap/Zend_Application应该更容易。膨胀：采埃孚组件是松散耦合的，您的自动加载器将只包含必要的代码。复杂性/文档：有一个 API 文档可以快速回答，参考指南详细介绍了工作原理。您可以跳过其中的部分内容。由于采埃孚提供了很多功能，所以有很多东西要写。
4赞
David Snabel-Caunt
3/12/2010
我认为学习曲线对于pestaa来说可能太陡峭了，但只要你对OOP和一些企业模式感到满意，你就会发现采埃孚的设计很好。也就是说，在保持向后兼容性的情况下，几年前的一些糟糕的设计选择仍然与框架一起使用。如果你认为缺乏严肃的愿景，你应该关注贡献者邮件列表，正如我们所说，2.0 正在设计中，并查看 2.0 路线图 j.mp/c0FeW1，其中框架正在从头开始重新设计
0赞
pestaa
3/12/2010
@Pekka：谢谢你，我应该更快地阻止CW:)。Yii最近大肆宣传，无论如何它不应该是一个交易破坏者。最后，这真的取决于你。我很高兴我能为你做出明智的决定做出贡献。@David Caunt：当你需要一个类似 Pear 的库时，解耦类是一个加分项，而当你只需要一个工作框架时，这是一个昂贵且臃肿的功能。即将到来的版本虽然是一个很好的观点（期待它！），但就像我们不应该等待最新的硬件一样，我们不应该总是等待下一个版本。我希望佩卡公布他的决定。
2赞
David Snabel-Caunt
3/12/2010
我仍然不明白 ZF 的昂贵或臃肿之处 - 当您使用组件时，PHP 仅包含框架中的文件。例如，如果从不引用Zend_Infocard，则该组件的文件永远不会加载到内存中，它们只会占用磁盘上的空间。如果你抱怨 MVC 堆栈和应用程序组件很慢，那么你就有一个有效的观点;)
2赞
Nick Edwards
#6
我作为唯一开发人员在一个项目中使用了采埃孚。虽然学习曲线相当陡峭，但我并没有遇到太多上述问题。总的来说，我发现这个框架非常灵活，当采埃孚的办公方式不适合我的需求时，组件的松散耦合使我很容易做自己的事情。
但是最近开始使用 python，我会说使用 python ;)
评论
0赞
clyfe
3/12/2010
等到你使用 Ruby（带有 Rails）......
评论