1

我使用 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(...);
    }
}

我的问题有两个部分；

  1. 哪一个是更好的实践？如果我使用第一个，我必须将数据库对象传递给每个使用 db 的类。如果我使用第二个，每个使用 db 的类都将依赖于 Common 类。

  2. 我使示例更简单。实际上我有一个数据库类扩展了 mysqli 和一个使用数据库类的 DatabaseTableManager 类。我将 GetTable() 函数添加到数据库类。我在这个函数 () 中创建了 DatabaseTableManager 对象，return new DatabaseTableManager($this, $tableNameFromArgument)因此我不必每次都传递 db 对象。在 DatabaseTableManager 类中，我构建了一些查询以使我的工作更轻松。

例如向表中插入一条记录；

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

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

4

3 回答 3

2

更好的解决方案是什么？

问题是什么？:) 所以首先从一般设计的角度来看，据说我们受益于不引入全局静态状态。这取消了单例和使用全局变量的资格。

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

实际上，对于“表管理器”，您已经这样做了（也许管理器不是一个好词（它不管理数据库中的表，它只是代表它们），但让我们先关注结构）。该类将生成表示表格的对象。

对于使用这些的应用程序的那部分，甚至不需要知道背后是哪种类型的数据库，因为您已经封装了这些细节。

当然，表管理器本身仍然需要具备这些知识。然而这没有问题，因为如果你需要改变它，你可以在一个中心位置改变它。

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

当然，与往常一样，您可能会遇到问题，但是如果您在应用程序中使用数据库的方式通常是基于表的，那么在我看来这并没有那么错误。您实现的模式可能会朝着Active Record的方向发展。众所周知，这适用于具有事务脚本的中小型应用程序。

于 2012-09-30T15:41:59.103 回答
0

  1. 这取决于。你想继承行指针的状态吗？如果是这样，请继续创建 Common 类。从设计的角度来看，依赖于数据库的代码被迫依赖于某种抽象，所以选择对你来说最灵活的东西。我个人只会有一个 DB 对象并传递它。单一类可能有优势。如果你能写一个更充实的例子，我们也许能提供更好的答案。

  2. 为什么不将方法放在数据库类中，而不是不必要地创建两个类和/或添加继承？将对象或变量传递给函数是正常行为，除非有东西在跟踪状态。您能否提供一个更完整的 Database 和 DatabaseTableManager 类示例？

于 2012-09-30T15:29:17.457 回答
0

我会按照您现在的方式保留它：

  • 你Someclass不依赖于任何其他类。
  • 在构造时注入数据库。这是测试的最佳选择。
  • 这是关注点分离。
  • 这个构造是最容易转换为真正的依赖注入器的，与控制反转容器结合使用。
于 2012-09-30T15:40:43.870 回答