gpt4 book ai didi

php - 将 PDO 准备好的语句放在 DB_Connector 类中的什么位置 - 在构造函数或函数中?

转载 作者:行者123 更新时间:2023-12-04 09:36:37 25 4
gpt4 key购买 nike

我的 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 - 将 PDO 准备好的语句放在 DB_Connector 类中的什么位置 - 在构造函数或函数中?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/62552793/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com