哪个 ORM 与 Symfony2 一起使用？ [关闭]答案

【问题标题】：Which ORM to use with Symfony2? [closed]哪个 ORM 与 Symfony2 一起使用？ [关闭]
【发布时间】：2011-12-20 05:56:42
【问题描述】：

我正在使用 Symfony2 开始一个新项目，但我不确定选择哪个 ORM。我听说过关于 Doctrine2 的一些坏事，尤其是在继承和 DQL 方面。看起来 Propel 死而复生，但另一方面，不能保证它会永远持续下去。

你有什么建议吗？

【问题讨论】：

记得在学习s1的时候，看到tuts中列出了一些替代方案，并采用了一对。我很遗憾，b/c 如果社区使用例如Doctrine，所有的 blogxamples 和 SO 评论都将围绕 Doctrine 展开。因此，即使 Propel 更适合（我不知道），D 仍然是务实的更好选择。

【解决方案1】：

我可以告诉你 Propel 是最适合与 Symfony2 一起使用的 ORM。它工作正常，没有计划停止它的活动。 Propel2 项目正朝着比 Propel 1.6.x 更好的方向发展（这真是太棒了）。

不要犹豫，使用 Propel，包括 Sensio Labs 在内的许多用户都在使用它！

有些地方我忘记了：

行为是 Propel 的一部分，在 Doctrine2 中没有提供。这意味着 Propel 正式支持他们并提供支持/改进。不确定教义。
推进速度非常快。我同意 Doctrine2 在大规模插入方面比 Propel 更好。
Propel 已有 10 年历史，稳定且被很多人使用。
没有其他语言可以用 Propel 学习。
Propel2 真正面向对象，这要归功于流畅的 API。
Doctrine2 ORM 不与 ODM 共享相同的 API，因此您可以像 D2 ORM 和 ODM 一样将 Propel 与 D2 ODM 一起使用，这里没有优点。
Propel 使用针对特定平台的代码生成，因此它针对您的需求进行了优化，并且由于运行时和生成器部件而快速。

我喜欢 Doctrine2 的几点：

问题不在于 Doctrine DBAL，而更多在于 Doctrine ORM。 Propel2 正在改进整个 Propel 1.6.x 代码。

哦，我用过 Doctrine2 很长时间了；）

【讨论】：

programmers.stackexchange.com 的问题是关于选择 ORM 与框架无关。据我了解，只是选择 ORM 作为独立工具。
这很相关，因为 Symfony2 是不可知的。正如我所说，几乎官方捆绑包也是不可知论者，使用 Doctrine ORM、ODM、Propel、Mandango 等都不是问题。
您可能应该在帖子中披露您与 Propel 的关系。

【解决方案2】：

我可以告诉你 Propel 是最适合与 Symfony2 一起使用的 ORM 我应该不同意。 Doctrine2 是 Symfony 的 native ORM。它包含在标准 Symfony 发行版中：http://symfony.com/download

Symfony 文档主要描述了使用 Doctrine，而不是 Propel。所以，我认为 Propel 的选择并不太明显。我认为你真的应该权衡后果。我更喜欢教义。

【讨论】：

没有什么是原生的，Doctrine 将从 Symfony2 核心（在 2.1 版本中）中删除，请阅读最后一篇 Fabien Potencier 博客文章。
@William DURAND 你指的是哪个博客？无论如何，即使这是真的，现在（2.x 分支）Doctrine 肯定是原生的。官方文档是关于 Doctrine，而不是任何其他 ORM。此外，Doctrine 的作者 Jonathan H. Wage 曾在 Sensio Labs 工作过一段时间。
这个：fabien.potencier.org/article/49/what-is-symfony2 该文档与 Doctrine 无关，除了一章也为 Propel 记录。伟大的捆绑包是不可知论者，与 Propel 一起工作就像魅力一样。我知道乔纳森在 SL 工作，如果他们雇用我，你会改变主意吗？我不这么认为；）我并不是说 Doctrine2 不适合 Symfony2，但在现实生活中使用它会很痛苦。基本用法还可以，但是如果你想做更多的东西，那就很难了。
@William DURAND：有没有说 Doctrine 在 2.1 中被删除了？我错过了这部分吗？ Fabien 只是说，Symfony 的 ORM 只是可选依赖项。
是的，明天的 IRC 会议将讨论这个问题。我邀请你来。 AFAIK Doctrine and Propel 将成为 Symfony2 “Bridge”的一部分。

【解决方案3】：

出于以下几个原因，我个人选择 Doctrine 2：

从概念上讲，它很容易理解。使用实体和实体管理器很简单。我喜欢实体不需要扩展任何基本模型类的方式（就像在 Doctrine 1 中一样）。
它有点是目前 Symfony2 的标准 ORM。虽然它可能没有得到 Symfony2 的正式“认可”，但它是大多数人正在使用的，因此在线上有大量的信息。这样做的价值是巨大的。

你提到你听说过“关于 Doctrine2 的坏事”——重要的是你要意识到没有 ORM 会是完美的。我遇到了一些问题，但只要你创造性地思考，你就能找到解决方案。有时，该解决方案意味着编写原始 SQL，无论 ORM 纯粹主义者怎么说。我没有遇到任何后悔使用 Doctrine 2 的情况。

我花了很多时间研究 Propel，但我就是不喜欢它的工作原理。这并不是说它是一个编程不佳的库，但对我个人而言，它并不适合。但是由于每个开发人员都不同，我能提供的最好建议是您查看这两个库的文档和使用示例。由于您将成为使用它的人，而不是我们，因此您需要选择您认为最能从中受益的库。

【讨论】：

嗯.. 不知道你在哪里看到的 DataMapper DP 比 ActiveRecord 方法更容易。我同意实体很简单但过于严格。问题是当你想构建真实的东西时，你必须了解 D2 背后的复杂性以及它是如何工作的，这并不容易。即使您想构建复杂的东西，ActiveRecord 也非常简单。
我熟悉 Doctrine 1 中的 ActiveRecord。我同意它使用起来很简单，但在很多情况下它不如数据映射器模式高效。
给我一个 DataMapper 比 AR 更高效的用例？例如，您是否尝试过嵌套树/集？
@Arms 你不认为它是在查询doctrine-project.org/2010/03/29/doctrine2-custom-dql-udfs.html 中使用 DQL 函数的教义 2 的可怕方式吗？我的意思是对于每个函数，我必须先添加扩展它。它很愚蠢。