Question

我使用PHP开发Web应用程序。我有很多使用数据库连接的类。

这是我通常使用的结构;

class SomeClass {
    private $db;

    function __construct(mysqli $db) {
        $this->db = $db;
    }

    function SomeFunction() {
        $this->db->query(...);
    }
}

这就是我想要使用的;

class Common {
    public static DB = new mysqli(...);
}

class SomeClass {
    function SomeFunction() {
        Common::DB->query(...);
    }
}

我的问题分为两部分;

哪一种更好的做法？如果我使用第一个，我必须将数据库对象传递给每个使用db的类。如果我使用第二个，则每个类使用db将依赖于Common类。
我让例子更简单。实际上我有一个Database类使用Database类扩展mysqli和DatabaseTableManager类。我将GetTable（）函数添加到Database类。我在这个函数（return new DatabaseTableManager($this, $tableNameFromArgument)）中创建DatabaseTableManager对象，所以我不必每次都传递db对象。在DatabaseTableManager类中，我构建了一些查询以使我的工作更轻松。

E.g。将记录插入表格;

$DB = new Database(...);
$myTable = $DB->GetTable('myActualTableNameInDatabase');
$myTable->Insert( array('col1' => 'val1', 'col2' => 'val2') );

所以我在其他课程中经常使用这个课程。当然，所有这些类都依赖于DatabaseTableManager类。什么是更好的解决方案？

Answer 1

什么是更好的解决方案？

有什么问题？ :)首先，从一般设计的角度来看，我们可以从不引入全局静态状态中受益。这取消了单身人士和使用全局变量的资格。

这减轻了做出很多选择的负担。通过它的构造函数将所需的Mysqli连接对象传递到需要它的类中就可以了。如果您担心“一直传递它”，请定义创建这些对象的位置。

事实上，你已经做过了“桌面管理员”（也许经理不是一个很好的术语（它不管理数据库中的表，它只是代表它们），但让我们关注结构第一）。该类将生成代表表格的对象。

对于正在使用这些内容的应用程序的那部分，甚至不需要知道后面是哪种数据库，因为你已经封装了这些细节。

表管理员本身仍然需要具备这些知识。但是这没有问题，因为如果您需要更改它，可以在中心位置更改它。

所以实际上我必须说，即使你热衷于寻找问题，你创造的东西看起来也很不错。

当然，一如既往，您可能会遇到问题，但是如果您在应用程序中使用数据库的方式通常是基于表的，那对我来说这看起来并不错。您实施的模式可能会朝Active Record的方向发展。众所周知，这适用于具有Transaction Scripts的小型到中型应用程序。

Answer 2

这取决于。你想继承行指针的状态吗？如果是这样，请继续创建Common类。从设计角度来看，依赖于数据库的代码必须依赖于某种抽象，因此请选择最灵活的代码。我本人只是有一个DB对象并传递它。单班可能有优势。如果你能写一个更加充实的例子，我们可以提供更好的答案。
为什么不将方法放在Database类中而不是不必要地创建两个类和/或添加继承？将对象或变量传递给函数是正常的行为，除非某些东西跟踪状态。你能提供一个更完整的Database和DatabaseTableManager类的例子吗？

Answer 3

我会按你现在的方式离开它：

您的Someclass不依赖于任何其他课程。
在施工中注入DB。这是测试的最佳选择。
这是一个关注点的分离。
这个构造最容易转换为真正的依赖注入器，并与Inversion of Control容器结合使用。

在PHP中选择设计模式？

3 个答案: