为其他 DBMS 分层 PHP 应用程序答案

【问题标题】：Layering PHP Applications for other DBMS为其他 DBMS 分层 PHP 应用程序
【发布时间】：2009-07-04 22:39:39
【问题描述】：

我目前正在编写一个实现 MVC 并很好地减少复杂事物的 Web 应用程序。然而，我已经思考了几个小时，为 Oracle、PostgreSQL、Firebird 等未来的数据库系统做些什么。

然后再一次在逻辑中实现这些适配器是什么让我着迷，我应该用大量的 SWITCH 来触发它吗？在这种情况下我该怎么办？

【问题讨论】：

【解决方案1】：

对此的典型答案是在您的框架中使用 ORM 功能。您可以将模型视为数据对象，也可以使用一些组合并让模型具有数据对象。无论哪种方式，您的数据对象都应该是相当抽象的，并且主要使用方法编译 DB 查询查询 - 就像 Zend 框架使用 Select 对象一样。这使您可以 a) 将 sql 排除在对象之外并 b) 替换实际生成 sql 的对象。

因此，如果您的数据对象都继承自同一个 ORM 基类，则可以为该基类提供一个它发送查询的 DB 对象。如果你正确地使用它，ORM 基类将不知道 DB 类的类型：数据对象编译一个选择对象并将其交给 DB 对象，然后以它认为最好的方式解释它。

简短的回答：不，不要使用一堆 switch 语句:)

【讨论】：

我已经计划了一个星期来使用 Doctrine ORM (doctrine-project.org)，因为我不想创建一个愚蠢的类来包装 MySQL 的东西。不过我还是有点犹豫，因为 ORM 对我来说还是一个新名词。 Doctrine ORM 会是答案吗？
我对教义一无所知，从未使用过。但是，总体而言，使用 ORM 是代码重用方面的一大进步，并且总体上使您的生活更轻松。使用已建立的代码库可能会更好，应该有大量的良好实践可供学习。

【解决方案2】：

然而，我已经思考了几个小时，要为未来的数据库系统做些什么，比如...

You’re NOT gonna need it!

【讨论】：

虽然记住这一点是一件好事，但如果您的应用程序从未考虑到这一点，那么重构您的应用程序以能够在主要数据库之间切换可能会是一个巨大的痛苦。不要用现在的小收益换取以后的巨大痛苦——只有当你确定以后可以像现在一样轻松地实现 DB 切换时，才能进行权衡。
您上一次必须更改现有应用程序的数据库引擎是什么时候？我必须坚持不同意你的优先级；我说，只有在您确定需要切换数据库时（例如：有一个具体的用例）才进行权衡。对数据库进行抽象可能还有其他更有效的原因，但这不是一个原因。
我想分享一些东西，那就是我打算开源我正在编写的应用程序。当然，甚至开始考虑提供其他适配器似乎还为时过早。我相信 ORM 的使用可能是正确的，但我想时间最终会证明它的性能以及我的决定是否正确。记住（您发布的链接）以解决当前的问题和需求是一件好事。

【解决方案3】：

如果您想要一个用于 PHP 的轻量级 ORM，我会查看 Outlet。它应该适用于任何标准 PDO 数据库类型。

【讨论】：

【解决方案4】：

我会避免 ORM 层，这是 Drupal 开发人员不得不说的

http://www.garfieldtech.com/blog/orm-vs-query-builders

【讨论】：