我为一个拥有大型遗留代码库的网站工作，该网站使用原始的PHP MySQL API拥有数百个自定义mysql查询。 出于安全原因，我们希望重写模型以删除直接编写的查询。
我们最初的计划是简单地重写我们的查询，以使用 PDO PHP 扩展来访问我们的数据库。然而，我们随后开始研究像Propel和Doctrine这样的ORM，实际上已经决定尝试使用Propel。
然而，我开始怀疑这对我们来说是否是矫枉过正——重写我们的模型本身就是一项艰巨的工作。为了实现这一点，我们将尝试复制模型的现有函数 - 这意味着在关联数组中返回所有数据。但是，如果我们这样做，我们基本上会失去使用ORM系统的大部分好处吗？
另一个问题是，我们的系统严重依赖于缓存查询结果，并使用命名空间系统使结果无效。我们起初认为扩展Propel来处理结果缓存可能不太难，但互联网搜索表明，这不是人们通常使用Propel做的事情;此外，Doctrine似乎内置了结果缓存。
如果我们以关联数组的形式返回查询的结果，并且没有充分利用数据对象，那么使用 Doctrine 或 Propel 是否会获得其他好处，从而值得使用 ORM 的开销？我能想到的最好的论点是，在我们完成模型大修之后，我们至少可以开始尝试在新系统中充分利用ORM，并且也许将来可以开始大修旧系统以利用它。
所以问题是：如果我们不打算使用 ORM 返回对象，我们最好直接使用 PDO 吗？或者，如果使用ORM还有其他优点，那么Doctrine上的内置缓存是否是一个杀手级功能（如果我们需要缓存），或者这是可以添加到Propel中的东西？
如果我们不打算使用 ORM 返回对象，我们最好直接使用 PDO 吗？
在某些时候，每个人都放弃了ORM，只依赖PDO。那是因为补水很贵。
或者，如果使用ORM还有其他优点，那么Doctrine上的内置缓存是否是一个杀手级功能（如果我们需要缓存），或者这是可以添加到Propel中的东西？
您可以使用 Propel 或 Doctrine 并决定返回对象，而不是数组。您还可以在这些 ORM 之一之上使用缓存层。Doctrine 在他们的"公共"包中提供了一个缓存层（我说的是 Doctrine2，无论如何不再支持原则 1）。Propel不提供缓存层，因为有很多现有的库。
将缓存层与 Propel 一起使用是可行的，只需选择一个缓存库，您就可以准备好了。顺便说一句，如果你想缓存生成的SQL查询，Propel提供了一个查询缓存行为。
总而言之，使用缓存层不是与ORM绑定，而是与您的应用程序绑定。