对Zend框架的承诺 - 任何反对的论据？

Question

我正在翻新一个我已经工作了很多年的大型CMS.产品本身很棒,但是一些组件,例如数据库和翻译类,需要紧急更换 - 部分是自制的,早在2002年,随着时间的推移会变得有点混乱,并且在安全审计中可能会遇到麻烦.

所以,我一直在密切关注一些框架(或者更确切地说,组件库,因为我不打算改变CMS的基本结构),最终还是喜欢Zend Framework.他们提供了一个坚实的MVC模型,但不强迫你进入它,他们提供了很多专业组件,显然已经得到了很多关注(你知道俄语有多个复数,你不能使用它们翻译它们一个简单的($number == 0) or ($number > 1)开关？我没有,但是Zend_Translate可以处理它.只是为了说明图书馆似乎已经建立的彻底程度.)

我现在确实处于不可逆转的状态,开始用Zend制造的系统替换系统的关键组件.我真的没有第二个想法 - 我肯定不想煽动火焰战 - 但在继续之前,我想退一步看看是否有任何反对将一个大系统与Zend紧密联系起来的事情框架.

我喜欢Zend:

• 据我所知,代码非常高质量
• 非常好的文档记录,至少关于如何工作的介绍(还没有使用详细的API文档)
• 由一家有兴趣看到框架繁荣的公司提供支持
• 在社区中受到好评,拥有可观的用户群
• 采用我喜欢的编码标准
• 附带一整套单元测试
• 在现代,专业的PHP开发方面,感觉像是正确的选择 - 或者至少是正确的选择之一.

我一直在考虑将ZF的功能封装和抽象到自己的类中,以便能够更轻松地切换框架,但我们得出的结论是,这不是一个好主意,因为:

• 这将是一个不必要的抽象层次
• 它可能会降低性能
• 使用框架的一大优势 - 熟悉其组件的开发人员基础的存在 - 将部分被取消

因此,对采埃孚的承诺将是深刻的.因此我的问题:

是否有任何实质性的反对承诺Zend框架？

你是否已经知道Zend Inc.的计划在2011年变得邪恶,并使其成为一个封闭的源库？Zend Inc. 是由吸血鬼经营的吸血鬼经营者想要占领地球吗？(评论中确定Zend实际上是由吸血鬼运行的.)当你将所有项目都转换为代码库时,是否存在概念缺陷？质量代码的外观是否是幻觉？代码看起来不错,但在我的四核工作站下面运行的速度非常慢吗？

接受答案

非常感谢大家的详细反馈.我希望我可以设置一个赏金,并在所有回答者之间平均分配.

在对ZF有利的许多意见中,有一个非常有根据的反对.我认真对待并密切关注替代方案,主要是Yii和Kohana.通过这种比较以及阅读关于ZF和竞争产品的更多观点,我可以看到,与更简约的框架相比,Zend可以在某些领域被视为臃肿.(我也可以看到,这种"膨胀"主要是有充分理由提供最大的灵活性.但是,你是否需要最大的灵活性并处理随之而来的复杂性,或者采用更简单的方法和明确的指导方针的问题是有效的.)

无论如何,我将为手头的项目选择Zend,因为我对框架的主要用途是作为组件库.我不想采用Zend的MVC模型,我只需要高质量的组件来进行国际化,会话处理等等.因为我正在构建可再发行的产品,所以Zend的灵活性(例如支持五种不同的字典格式)受到欢迎.此外,ZF似乎是唯一允许我想要的自由程度的框架(没有强制使用模式,文件结构......),据我所知,没有其他框架提供.

对于我希望在其中使用实际MVC功能的未来项目,并完全服从框架关于应用程序构建,命名,样式和过程的约定,我可能不一定会选择Zend,而是为了更简约像Yii或Kohana这样的框架.

Answer 1

Zend Framework是最佳选择.它们的最佳框架API,可读代码,语言惯例,良好的文档,社区,支持等等
我不喜欢它(主观的,mabe人会为此向我投票)是:

• Zend_Form有它的用途,但总的来说太突兀了,我只是想构建我的HTML而不是打击API和装饰器.
• Zend_Db_Table,功能强大,但它需要大量的工作才能实现你的目标,Rails教会我懒惰.不,我不想为模型编写3个类,一个用于表,一个用于行集,一个用于行,然后将它们彼此绑定,依此类推.我可能在某些时候需要表数据网关,但是现在我真的想要将这些数据与快速活动记录连接起来.
• 没有活跃的记录.随着php 5.3中的后期静态绑定,这可能会改变......

几个月我一直努力使用这两个,直到我终于拥有它.

我克服了他们(来自Ruby on Rails的想法)

• 使用普通视图助手而不是Zend_Form,如:
  echo $this->formText('email', 'you@example.com', array('size' => 32));
• 拥有自己的Active Record就像模型一样(http://www.phpactiverecord.org)
• 验证并过滤模型
• 对于真正极端的极端情况,人们可以回退到Zend_Form + Zend_Db_Table,虽然我从来没有觉得有必要.

编辑
有一些值得一试的新孩子,比如Laravel

ZF真正胜过其他框架的一件事是路由器,控制器和视图,约定,干净的可读代码,进程.

Answer 2

除非你期待一个拥有20多名开发人员的大型巨型项目,否则我会 - 如果我是你 - 会做任何事情,包括为了避免使用Zend Framework而牺牲一条胳膊和/或一条腿.

• 你发现的不错的选择可能看起来很方便 - 你发现其他1k +设置只是浪费时间和开发人员在库中的努力.您很快就会发现自己处于Customization Ocean的中间,被设置,接口和抽象类所淹没.
• 文档不仅详细,而且非常冗长和复杂(类似于库本身).我想要第三部分课程来帮助我,而不是让我陷入困境.
• 显然,最重要的因素是我的发展速度.如果没有一堆大学,Zend Framework应该认真考虑是否被放弃.
• 在Zend问题跟踪器中有太多人制作愿望,实施代码的人太多了.到目前为止,我还没有看到数百万行背后的任何严肃看法.

我的两分钱真的降到了一点:尽管(或者更确切地说,因为？)它得到了PHP公司的支持,它对于个人用途和中小型项目来说太过臃肿了.

我的团队目前正在使用Yii进行中型项目.它也不是完美的,但与大哥相比,它更有用,更适合开发人员.

Answer 3

我对ZF没有任何大的争论 - 恰恰相反; 当然,我还没有使用过所有组件(不确定是否有人),但是在浏览源代码时我从未见过任何看起来"糟糕"的东西.

在开始一个新项目时,我通常会自己选择Zend Framework,实际上,如果我是那个必须选择的人......

我想在列表中添加至少一个参数:

• Zend Framework可以与其他组件集成:您谈到在您的应用程序中使用ZF的组件,但没有谈到相反的情况.
  • 一个很好的例子是Doctrine (Symfony的默认ORM),它可以很容易地与ZF一起使用 - 而且Zend_Db在我看来比它好得多!

除此之外,我不得不说我同意你的每一点.

关于将ZF类封装到您自己的类中:是的,您可以这样做(我有时会这样做),但我不建议对所有内容执行此操作:在大多数情况下,它可能不是必需的.

关于未来 :

• Zend Framework是在BSD许可下发布的 - 这意味着存在的不能是封闭源的.
• 无论如何,关闭它将意味着它的结束 - 在PHP社区的背景下将是一个愚蠢的举动
• 关于ZF 2.0的工作刚刚开始(以PHP 5.3为要求,顺便说一下)
  • 也许,根据您的申请时间表,它可能会有趣吗？
  • 至少如果你不需要在至少几个月之前开始开发......