我的 Web 项目有一个名为 DB_CONNECTOR
的类,其中捆绑了与 mysql 数据库交互的所有函数。这些函数包括 get_user()
、add_user()
、change_user_attribute()
等等。在每个函数中都会执行一个 sql 查询,并且作为良好实践,我使用准备好的语句(带有命名参数)。
目前与数据库的连接是在类的构造函数中建立的,并且所有语句都在那里准备。我认为这是一个好主意,因此这些语句都立即准备好执行。
现在我意识到我的用例通常是创建一个 db_connector 对象,执行一个或两个函数,然后对象生命周期结束,在稍后的步骤中可能会构造(或不构造)一个新的对象。因此,我不再确定将准备好的语句放入构造函数中是否明智,因为可以预见的是,我最终会得到至少 20 个或可能更多的准备好的语句。
所以我的问题是:
- 即使只使用一两个语句,在构造函数中准备所有语句是否是一个好主意?
- 或者我应该在执行之前在函数中准备它们,以避免不必要的准备工作给数据库带来压力?
最佳答案
这个答案是基于我的经验和拙见,但我会尽力阐述我的论点,这样它不仅仅是一些随机的人的观点。
我认为数据库连接不一定是应用程序中的核心对象,更不用说是唯一的对象了。它期望为用户看到一个完全不同的类,因此您稍后可以为其他所有内容提供进一步的类。否则,您的应用程序最终将由 5000 行文件中的单个类组成,并且您的类将不适合在实例级别跟踪实体数据,并且您需要在方法调用中传递变量。这几乎是 OOP 服装中的过程代码。
此外,我认为让您的 User
类继承 Database
(尽管如此,这种情况很常见)是不切实际的。交错数据库连接和业务逻辑对象并没有真正简化应用程序设计,实际上使某些部分变得更加困难。
数据库层本身的设计非常标准化:
- 每个应用程序一个连接(或多个连接...您可能需要连接到多个源!)
- 每个查询一个语句。
这正是 PDO 的工作原理。
鉴于此,让数据库类成为实体的又一个依赖项而不是它们的祖 parent 项会更容易。这种依赖的注入(inject)可以通过不同的方式来完成:
将其设为类属性:
public function __construct(\PDO $connection) { $this->connection = $connection; }
将其传递给他们实际需要的方法(如果不是很多):
public function getOrders(\PDO $connection) { $stmt = $connection->prepare('SELECT ...'); }
...或者使用您可以在 Packagist 找到的那些奇特的依赖项注入(inject)容器之一。
请注意,还有 object-relational mapping (ORM),active record pattern ...这些是完全不同的解决方案系列,可能适合您的需求,也可能不适合您的需求,具体取决于您的用例,但不是我在这里描述的。
话虽如此,很明显您应该在需要的地方准备报表。这种设计甚至不允许其他情况;-)
关于php - 在 DB_Connector 类中的何处放置 PDO 准备好的语句 - 在构造函数中还是在函数中?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/62552793/