3

我经常在 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吗？

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

4

2 回答 2

0

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

于 2011-10-02T20:54:46.487 回答
-1

老实说，我只是对 SQL 进行硬编码，因为：

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

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

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

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

但是，如果您决定使用这样的抽象层：维基百科有更多信息。

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

于 2011-10-02T21:06:28.357 回答