1

我为一个拥有大量遗留代码库的网站工作，该代码库有数百个自定义 mysql 查询，使用原始的 PHP MySQL API。出于安全原因，我们想重写我们的模型以删除直接编写的查询。

我们最初的计划是简单地重写我们的查询以使用 PDO PHP 扩展来访问我们的数据库。然而，我们随后开始研究像 Propel 和 Doctrine 这样的 ORM，实际上已经决定尝试使用 Propel。

然而，我开始怀疑这对我们来说是否是矫枉过正——重写我们的模型本身就是一项艰巨的工作。为了完成这项工作，我们将尝试复制模型的现有功能——这意味着将我们所有的数据返回到关联数组中。但是，如果我们这样做，我们是否基本上失去了使用 ORM 系统的大部分好处？

另一个问题是我们的系统严重依赖于缓存查询结果，并使用命名空间系统使结果无效。起初我们认为扩展 Propel 来处理结果缓存可能并不太难，但互联网搜索表明这不是人们通常使用 Propel 做的事情；此外，Doctrine 似乎内置了结果缓存。

如果我们将查询的结果作为关联数组返回，而不是充分利用数据对象，那么我们可能从使用 Doctrine 或 Propel 获得的其他好处是否值得使用 ORM 的开销？我能想到的最好的论点是，在我们完成对模型的大修之后，我们至少可以开始尝试在新系统中充分利用 ORM，并且也许将来可以开始大修旧系统以利用其中。

所以问题是：如果我们不打算使用 ORM 返回对象，我们是否最好直接使用 PDO？或者，如果使用 ORM 有其他优势，Doctrine 的内置缓存是一个杀手级功能（如果我们需要缓存），还是可以将其添加到 Propel 中？

4

1 回答 1

2

如果我们不打算使用 ORM 返回对象，我们是否最好直接使用 PDO？

在某些时候，每个人都放弃了 ORM，只依赖于 PDO。那是因为水化是昂贵的。

或者，如果使用 ORM 有其他优势，Doctrine 的内置缓存是一个杀手级功能（如果我们需要缓存），还是可以将其添加到 Propel 中？

您可以使用 Propel 或 Doctrine 并决定返回对象，而不是数组。您还可以在其中一个 ORM 之上使用缓存层。Doctrine 在他们的“commons”包中提供了一个缓存层（我说的是 Doctrine2，Doctrine 1 无论如何都不再支持了）。Propel 没有提供缓存层，因为有很多现有的库。

在 Propel 中使用缓存层是可行的，只需选择一个缓存库就可以了。顺便说一句，如果你想缓存生成的 SQL 查询，Propel 提供了查询缓存行为。

总而言之，使用缓存层并不依赖于 ORM，而是依赖于您的应用程序。

于 2012-08-21T09:32:52.153 回答