使用分离层（PHP 和 WordPress）与数据库交互

Question

我经常在 PHP，特别是 WordPress 插件中看到人们直接在他们的插件中编写 SQL...我学到的东西的方式，一切都应该分层处理...所以如果有一天给定的要求层改变，我只需要担心改变一切接口的层。

现在我正在编写一个层来连接数据库，这样，如果我与数据库交互的方式发生变化，我所要做的就是改变一层，而不是我创建的 X 个插件。

我觉得这似乎是其他人过去可能遇到过的事情，而我的方法效率低下。

我正在编写诸如

之类的类

Table
Column
Row

这让我可以使用给定的对象创建数据库表、列和行，并使用特定的方法来处理它们的所有功能：

$column = new \Namespace\Data\Column ( /* name, type, null/non-null, etc... */ );
$myTable = new \Namespace\Data\Table( /* name, column objects, and indexes */ );

\Namespace\TableModel.create($myTable);

我的问题是……

其他人是否已经编写了一些东西来提供不同层之间的某种分离？

如果没有，从长远来看，我的方法是否会有所帮助，还是我在浪费时间？我应该像其他人一样分解和硬编码 sql 吗？

如果它有助于我自己编写这个，有什么方法可以让我更有效地处理它吗？

Answer 1

您似乎在寻找 ORM。 这是一个：http://www.doctrine-project.org/docs/orm/2.0/en/tutorials/getting-started-xml-edition.html

Answer 2

说实话，我只是硬编码 SQL，因为：

1. 其他人也这样做。如果他们希望从 MySQL 更改为其他内容，则需要重写 WordPress 的大部分内容。如果整个系统的其余部分仍然只能使用硬编码的 SQL，那么为插件编写完美的层只是浪费时间。

2. 我们并不生活在一个完美的世界中。太多的抽象——很快或很晚——最终会导致性能和其他问题，我什至还没有想到。把事情简单化。此外，使用 SQL，您可以从一些性能“黑客”中受益，这可能不适用于其他系统。

3. SQL 是一种被广泛接受的标准，已经可以被视为抽象层。例如，甚至可以通过类似 SQL 的语法访问 Facebook 的 Graph（请参阅FQL）。如果您想更改为另一个数据源，您可能会发现一些支持 SQL 语法的层！从这个意义上说，您甚至可以说SQL 已经是某种抽象层。

但是：如果您决定使用 SQL，请务必使用 WordPress 的$wpdb。使用它，您是安全的，因为 WordPress 负责连接到数据库、形成查询等。如果有一天，WordPress 决定从数据库更改为其他东西，他们将需要创建一个$wpdb-layer 到那个新的源——为了向后兼容。另外，很多通用请求已经在$wpdb中作为函数（比如$wpdb->insert()），所以不需要直接硬编码SQL。

但是，如果您决定使用这样的抽象层：维基百科有more information。

更新：我刚刚发现 CMS Drupal uses a database abstraction layer - 但他们仍然使用 SQL 来形成查询，用于所有不同的数据库！我认为这很清楚地表明，SQL 已经可以用作抽象层了。