我正在为我正在启动的web应用程序选择一个PHP框架。我过去从未真正使用过框架，但这个项目非常需要。
我一直在争论通常的嫌疑犯;CakePHP, Zend Framework和Symfony。我一直在来回讨论哪个框架最适合我和这个项目。我倾向于CakePHP，但我仍在研究。
我的问题不是什么框架是最好的。我知道没有真正的答案，有大量的帖子与这个主题相关。我的问题与模型和ORM有关。我读过很多关于orm很慢的文章，我很关心速度。我非常擅长编写SQL，并且在过去一直试图将所有数据库交互保持在存储过程中。我正在寻找一些关于使用CakePHP的ORM或学说与Zend或Symfony，而不是保持一切在存储过程的反馈。我知道存储过程会更快，但是如果我不使用ORM，我还会失去什么呢?我知道ORM将给我提供数据库抽象，但在我看来，它只是帮助那些不写SQL的人。我也知道我对orm了解不够。
如果有人能给我一些关于这个和哪个框架可能是最好的基于使用或不使用ORM的反馈。
提前感谢您的帮助。
0)爆炸的努力
使用ORM的主要优点是您不需要花费太多时间处理持久层。预先编写的ORM(我曾使用过EclipseLink)将提供大量您在自定义编写的存储过程中可能无法获得的功能。我认为值得考虑的是，你要花多少时间来编写持久化层。
<1)缓存/strong>
所有主要的orm都提供了多级分布式缓存。结合命名/预定义查询，您可以获得实际上不需要进入数据库的SQL查询。这可以给你很好的表现。
<2)抽象/strong>
orm允许您在一个位置定义表布局，然后它们管理列/表和对象之间的所有痛苦映射。有些允许您在不更改任何代码的情况下重新映射列、表和模式名称。如果你和喜欢改变周围事物的人一起工作，这真的可以简化事情。
3)速度
一些orm的性能可能很差，但这实际上取决于您如何使用它。我发现你最终往往会对事情进行过度的查询。另一方面，您可以获得内置查询分析器之类的东西。如果发现无法获得所需的性能，可以为查询编写自定义SQL。
Mark Robinson给出了一个很好的回应。我要用我们在Doctrine2上的经验来支持他的话。
我选择使用Doctrine2作为我们的ORM与Zend框架一会儿。我们的项目仍在开发中，但选择D2是我们一点也不后悔的决定。虽然您仍然需要对数据体系结构进行大量考虑，但D2为您提供了灵活性，可以在以后需要时修改该模型。它允许我们在早期阶段快速尝试，并在后来我们认为事情不太正确时提供成长和改变的空间-这种情况发生了。
关于Mark关于抽象的观点。我喜欢D2的另一件事是，我们使用的是普通的老式PHP对象。不要低估从对象角度思考问题的能力——无论是对负责数据建模的人员还是使用数据的开发人员来说——相信我，这会让你的生活更轻松。此外，拥有ORM映射的内联文档(如果您选择docblock方法)是很好的。正确,性能。正如马克所说，有很多方法和手段可以加快速度，但总会有一些开销。无论何时引入另一个软件层，都会对性能造成一些影响，但这是一种权衡。对我们来说，使用ORM的优势和性能之间的权衡是值得的。如果没有ORM，我们将花费更多的时间调试代码，而无法完成工作。
无论如何，D2可以帮助您缓存查询，结果和元数据。虽然在开发过程中你可能只想要一个数组缓存，但当你去测试和部署时，APC、memcache等设施是很好的。如果你足够勇敢，你甚至可以发展出自己的。 http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html希望这对你有帮助，我可能漏掉了一些东西，但如果你有任何问题，尽管提出来，我会尽力的。
框架主要实现三种特性:
- "获取请求"answers"呈现页面"之间的流程。这是你放MVC，路由器等的地方。
- 管理模型及其持久性的方法。你会看到ORM, DBAL, DAO等缩写词
- 组件。功能，通常也可以独立工作。如Xml解析，i18n处理，pdf生成…
当你选择框架时，它实际上意味着你选择了1)。这是你必须坚持的东西，这是你的应用程序的流程。2)和3)?你可以积分那些你喜欢的。作为一个例子，我使用Zend框架的大部分组件，但使用Doctrine ORM 2和Symfony的依赖注入。我的一个朋友在Symfony 2上，也使用Doctrine ORM，但是使用Zend的相关组件来生成pdf和邮件管理。
你需要知道的另一件事是，目前是否有"第二代"php框架/orm，(重新)编写以利用php 5.3的新特性，和/或解决他们(几乎)都有的一般性能/耦合问题。其中一些已经准备生产，一些仍在开发中:
- 理论ORM 2(生产就绪)
- Symfony 2(生产就绪)
- CakePhp 2(目前在RC 2中，但当你的项目准备好它应该是稳定的)
- Zend Framework 2(仍在积极开发中，但通常不会持续这么长时间)
- FLOW 3 (beta2，应该也很快准备好了)
对于ORM部分，我建议使用一个，特别是Doctrine的。@Mark和@iainp999完美地解释了原因。
orm是为那些不"操纵"SQL的程序员准备的!
是的，orm使编写简单的CRUD内容变得更容易(或者至少需要更少的代码行)，但是当您遇到更复杂的需求时，就像试图从十英尺远的地方用一块湿意大利面编写SQL一样。
所以还是用SQL吧。
值得看看像"SQLMap"这样的东西，它是从映射的"R"关系端开始的ORM(大多数尝试将"O"对象映射到表上)。这将允许您自己编写SQL并生成适当的"助手"类，以便在程序中轻松访问结果。