在 DB_Connector 类中的何处放置 PDO 准备好的语句 - 在构造函数中还是在函数中？

Question

我的 Web 项目有一个名为 的类DB_CONNECTOR，其中捆绑了与 mysql 数据库交互的所有函数。这些函数包括get_user()、add_user()、change_user_attribute()等等。在每个函数中都会执行 sql 查询，并且作为良好实践，我使用准备好的语句（带有命名参数）。目前，与数据库的连接是在类的构造函数中建立的，并且所有语句都在那里准备。我认为这是一个好主意，因此所有语句都立即准备好执行。现在我意识到我的用例通常是创建一个 db_connector 对象，执行一个或两个函数，然后对象生命周期结束，在稍后的步骤中可能会构造（或不构造）一个新的对象。因此，我不再那么确定将准备好的语句放入构造函数中是否明智，因为可以预见的是，我最终会得到至少 20 个或可能更多的准备好的语句。所以我的问题是：即使只使用一两个语句，在构造函数中准备所有语句是否是一个好主意？或者我应该在执行之前在函数中准备它们，以避免不必要的准备工作给数据库带来压力？

Answer 1

这个答案是基于我的经验和拙见，但我会尽力阐述我的论点，这样它不仅仅是一些随机的人的观点。

我不认为数据库连接一定是应用程序中的核心对象，更不用说是唯一的对象了。它期望为用户看到一个完全不同的类，因此您稍后可以为其他所有内容提供进一步的类。否则，您的应用程序最终将由 5000 行文件中的单个类组成，并且您的类将不适合在实例级别跟踪实体数据，并且您需要在方法调用中传递变量。这几乎就是 OOP 服装中的程序代码。

另外，我不认为让你的User类继承Database（尽管如此）是很实际的。交错数据库连接和业务逻辑对象并没有真正简化应用程序设计，实际上使某些部分变得更加困难。

数据库层本身的设计非常标准化：

• 每个应用程序一个连接（或更多...您可能需要连接到多个源！）

• 每个查询一个语句。

这正是 PDO 的工作原理。

鉴于此，让数据库类成为实体的又一个依赖项而不是它们的祖父母项会更容易。这种依赖关系的注入可以通过不同的方式完成：

使其成为类属性：

public function __construct(\PDO $connection)

{

    $this->connection = $connection;

}

将其传递给他们实际需要的方法（如果不是很多）：

public function getOrders(\PDO $connection)

{

    $stmt = $connection->prepare('SELECT ...');

}

• ...或者使用您可以在 Packagist 找到的那些奇特的依赖注入容器之一。

请注意，还有对象关系映射(ORM)、活动记录模式……这些是完全不同的解决方案系列，可能适合您的需求，也可能不适合您的需求，具体取决于您的用例，但不是我在这里描述的内容。

---

话虽如此，很明显，您在需要的地方准备了报表。这种设计甚至不允许其他情况;-)