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