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 回答