我有 CodeIgniter 和 Cake PHP 的现场项目经验。但是现在我需要处理一个两者都不适合的大型项目。我几乎决定使用 symfony 1.4（根据我客户的要求，2.0 不是一个选项）。
在 Symfony 1.4 中，我也对 ORM 选择感到困惑：Doctrine 还是 Propel？我浏览了几个链接。迄今为止最好的发现是 PHP ORMs: Doctrine vs. Propel。
然而，所有这些比较似乎至少有两年的历史，而且从那以后世界肯定会发生很大变化。我对编码风格没有任何问题；我对所有 Active Record、Criteria、DQL 或其他什么都很好。对我来说，性能比编码风格最重要。我主要关心处理大量数据时的性能，可能是集群数据库下多个表中的数百万行。不幸的是，目前我的经验不足以就此事做出独立决定。
谁能解释一下 Symfony 1.4 下 Propel/Doctrine 的性能？除了性能之外，在选择 PHP ORM 时还有其他值得注意的因素（编码风格除外）吗？
tl;dr：我使用 Doctrine 很长时间了，如果我必须开始新的东西，我会选择 Propel。
这是一个常见的问题，几乎没有好的答案。但我只是给你我的观点。
我从第一个 alpha 开始就使用 Doctrine（以及旧的 symfony 0.63）。我们选择 Doctrine 而不是 Propel，因为 Doctrine 支持 PDO（PHP 原生）并且 Propel 仍在Creole（非原生）上运行。与 PDO 相比，克里奥尔语非常慢（当然）。
最近，Doctrine 增加了一个迷失的魔法。我的意思是，你可以打电话给getField,findOneByField一切，它会返回你想要的。这真的很棒，而不是必须构建自己的 getter 和 setter。魔术在那个时候真的很流行。
使用 Doctrine 编写查询真的很容易，而不是来自 Propel 的痛苦的 Criteria 和 Criterion，这真的很冗长。我真的是 Doctrine 的粉丝，并建议大家开始使用它而不是 Propel。
然后，Propel 从 1.3 开始切换到 PDO，并开始有一个很好的 API 来编写查询，几乎与 Doctrine 相同的方法。主要区别在于 Propel 会生成所有魔法物品，而 Doctrine 则是动态构建的。这是我认为最大的不同。
Propel 在这段代码中没有任何魔力。它会在您构建模型时生成所有 getter/setter、join 等。Doctrine 在运行查询时会执行所有操作。这对于中小型项目来说是可以的，但它开始变得更大，它将成为一个缓慢的解决方案。而且它也非常适合调试，因为您可以在生成的类中找到代码，您不必从一个类跳到另一个类来查找处理这种情况的全局方法。
两个 ORM 都使用行为。我喜欢行为。它们在 Doctrine 和 Propel 中以不同的方式处理。Doctrine 仍然使用它的魔法来处理它们，其中 Propel 从类内部的行为生成所有内容（从生成的类中多一点而不是魔法一点）。
到目前为止，由于 1.2.x 分支几乎死了（最后一个版本是2010年 8 月 24 日）。正如你在github上看到的那样，Propel 仍然很活跃，非常活跃。
我仍然在 Doctrine 工作，但几年以来我从 Propel 学到了很多东西。我在 Doctrine 上建立了一些个人项目。到今天为止，我改变了主意，如果我必须开始一个新项目，我会使用 Propel 来完成。
几个链接：