PHP 框架和 ORM 与存储过程

Question

我正在为我正在启动的 Web 应用程序选择 PHP 框架。我过去从未真正使用过框架，但这个项目非常需要。

我一直在通常的嫌疑人之间进行辩论； CakePHP、Zend 框架和 Symfony。我一直在反复讨论哪种框架最适合我和这个项目。我倾向于 CakePHP，但我仍在研究。

我的问题不是什么框架最好。我知道对此没有真正的答案，并且有大量与此主题相关的帖子。我的问题与模型和 ORM 有关。我读过很多关于 ORM 速度慢的文章，我担心速度。我非常擅长编写 SQL，并且过去曾尝试将所有数据库交互保留在存储过程中。

我正在寻找一些关于使用 CakePHP 的 ORM 或 Doctrine 与 Zend 或 Symfony 的反馈，而不是将所有内容保存在存储过程中。我知道存储过程会更快，但如果我不使用 ORM，我还会丢失什么？我知道 ORM 会给我数据库抽象，但在我看来，这只会帮助不编写 SQL 的人。我也知道我对 ORM 的了解还不够。

如果有人可以给我一些反馈，以及基于使用或不使用 ORM 的最佳框架。

提前感谢您的帮助。

Answer 1

0) 全力以赴

ORM 的主要优势在于您无需花费太多时间处理持久层。预先编写的 ORM（我曾与 EclipseLink 合作过）将提供大量您可能不会在自定义编写的存储过程中获得的东西。我认为值得考虑花多少时间来编写持久层。

1) 缓存

所有主要的 ORM 都提供多级分布式缓存。结合命名/预定义查询，您可以获得实际上不必进入数据库的 SQL 查询。这可以为您提供出色的性能。

2) 抽象

ORM 允许您在一个位置定义表布局，然后它们管理列/表和对象之间的所有痛苦映射。有些将允许您重新映射列、表和模式名称，而无需更改任何代码。如果您与喜欢围绕这一点进行更改的人一起工作，可以真正简化事情。

3) 速度

某些 ORM 的性能可能会很差，但这实际上取决于您如何使用它。我发现您最终往往会过度查询事物。另一方面，您可以获得内置查询分析器之类的东西。如果您发现自己没有获得所需的性能，您可以为查询编写自定义 SQL。

Answer 2

马克罗宾逊给出了很好的回应。我将通过提供我们在 Doctrine2 方面的经验来支持他所说的话。

不久前，我选择使用 Doctrine2 作为我们的 ORM 和 Zend 框架。我们的项目仍在开发中，但选择 D2 是一个我们没有后悔的决定。虽然您仍然需要对数据架构进行大量思考，但 D2 为您提供了在以后需要时能够修改该模型的灵活性。它使我们能够在早期阶段快速尝试，并在以后确定事情不太正确时有成长和改变的空间 - 它发生了。

关于马克关于抽象的观点。我喜欢 D2 的另一件事是我们正在使用普通的旧 PHP 对象。不要低估能够根据对象进行思考的力量——对于负责建模数据的人员和使用数据的开发人员来说——它会让你的生活更轻松，相信我。此外，拥有 ORM 映射的内联文档（如果您选择 docblock 方法）也很好。

对，性能。正如马克所说，有一些方法和方法可以加快速度——但总会有一些开销。每当您引入另一个软件层时，都会对性能产生一些影响，但这是一种权衡。对我们来说，权衡——使用 ORM 与性能的优势——是值得的。我们会花更多时间调试代码，而没有 ORM 就无法完成任务。

无论如何，D2 可以帮助您缓存查询、结果和元数据。虽然您可能在开发过程中只需要一个阵列缓存，但当您去测试和部署时，APC、memcache 等工具的存在非常好。如果你有勇气，你甚至可以开发自己的。

http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html

希望对您有所帮助，我可能错过了一些东西，但如果您有任何问题，请直接提出来，我会尽力而为。

Answer 3

一个框架主要实现了三种功能：

1. “获取请求”和“呈现页面”之间的流程。那是你放了 MVC、路由器等东西......
2. 管理模型的方式及其持久性。这就是您看到 ORM、DBAL、DAO 等首字母缩略词的地方
3. 组件。功能，通常也可以独立工作。像 Xml 解析、i18n 处理、pdf 生成...

当您选择框架时，实际上意味着您选择了 1)。这是你必须坚持的事情，它是你的应用程序的流程。 2) 和 3) ?您可以集成您喜欢的那些。例如，我在 Zend Framework 上使用它的大部分组件，但使用 Doctrine ORM 2 和 Symfony 的依赖注入。我的一个朋友在 Symfony 2 上，也使用 Doctrine ORM，但它是使用 Zend 的相关组件生成 pdf 和邮件管理的。

您需要知道的另一件事是当前是否存在“第二代” php 框架/orm，（重新）编写以利用新的 php 5.3 功能和/或解决一般性能/@ 987654321@ 他们（几乎）都有的问题。其中一些已准备好生产，一些仍在开发中：

• Doctrine ORM 2（生产就绪）
• Symfony 2（生产就绪）
• CakePhp 2（目前在 RC 2 中，但当您的项目准备就绪时，它应该已经稳定了）
• Zend Framework 2（仍在积极开发中，但通常不会这么久）
• FLOW 3（beta2，也应该很快准备好）

对于 ORM 部分，我建议使用一个，尤其是 Doctrine 的。 @Mark 和 @iainp999 完美地解释了原因。

Answer 4

ORM 适用于不“grock” SQL 的程序员！

是的，ORM 使编写简单的 CRUD 内容变得更容易（或者至少需要更少的代码行），但是当您遇到更复杂的需求时，就像尝试在 10 英尺外用一块湿意大利面编写 SQL。

所以坚持使用 SQL。

值得看一下像“SQLMap”这样的东西，它是从映射的“R”关系端开始的ORM（大多数尝试将“O”对象映射到表上）。这将允许您自己编写 SQL 并生成适当的“帮助程序”类以轻松访问程序中的结果。