PHP用户类应该扩展数据库类吗？

我不确定这样做是否完全是错误的，所以我正在寻求一些建议

我已经建立了一个数据库类，构造函数建立了到MySQL数据库的连接

我一直在研究和全局变量，但似乎总有人反对这两个变量中的任何一个

---

我正在试验一个扩展数据库类的用户类，因此我可以调用PDO函数/方法，但要维护单独的用户类代码。这是一件愚蠢的事情吗？

我看不出它在特定情况下有什么问题。您可以使用它来完成一些简单的事情，比如将用户的DB凭据包装到对象中，这样他们就不必在使用DB对象的任何地方都指定它们

$db = new UserDB();

会比

$db = new StandarDB($username, $password, $default_db);

---

通常应将连接传递给用户，以便用户类将数据库类型对象带入其构造函数，然后使用该数据库对象对数据库执行查询。这样，数据访问逻辑与业务逻辑保持分离。这叫做构图，与你所说的相反，它是内在的

如果你真的想变得技术化，最好是让一个用户对象只包含公共变量，然后你就可以使用“服务”来实现你的业务逻辑

class UserService implements IUserService
{
    private $_db;
    function __construct(IDb $db) {
        $this->_db = db;
    }

    function GetAllUsers() {
        $users = Array();

        $result = $this->_db->Query("select * from user")

        foreach($result as $user) {

            //Would resolve this into your user domain object here
            users[] = $user;
        }
        return users;
    }
}

---

那么，问问自己，

User

是否是

数据库的特例。我不知道别人是怎么看的，但我会有点生气。我想你需要的是读一下这本书

至于解决你的“人们告诉我全球都是坏的”问题，这里有两个视频你应该看：




根据对象的定义，它非常简单。它是对数据的封装和对数据进行的操作，所以如果我们只考虑理论观点，它将使我们处于令人愉悦的环境。
我的建议是使用通用的基本crud操作和使用PDO、ADO或其他一些数据库抽象库的简单查询执行创建一个抽象数据访问类。现在，将该类用作大多数模型类（如用户）的父类

现在basic由抽象数据访问类提供，您可以编写特定于用户对象的行为，例如通过使用抽象父类的简单查询接口为用户获取所有帖子

这种方法将在耦合功能方面带来更多的模块化，以及更多的可读性和重用能力。
OOP中类扩展背后的思想是子类与父类相关。例如，一所学校可能有一个人班，由教师和学生组成延伸班。这两个子类都是人，因此对他们来说，扩展Person类是有意义的。但是用户不是数据库的一种类型，所以如果您将其作为扩展，有些人可能会感到不安

就我个人而言，我会将数据库对象作为参数发送给构造函数中的用户类，并简单地将该对象分配给类属性。例如：

class User
{
    protected $db;
    function __construct($username, $password, $db)
    {
        //some code...
        $this->db = $db;
    }
}

或者，尽管有些人可能会为此对您大喊大叫，但您可以使用global关键字在全局范围内继承一个变量，以便在方法中使用。缺点是，您必须在每个需要它的方法中将它声明为全局的，或者您可以这样做：

class User
{
    protected $db;
    function __construct($username, $password)
    {
        global $db;
        //some code...
        $this->db = $db;
    }
}

但在回答您的问题时，不，我认为您不应该让用户成为数据库的扩展；尽管它可以满足您的需要，但它不是一种正确的面向对象实践。
您的用户功能是什么？他们应该怎么做？添加新用户，更新用户详细信息等…如果您将用户数据存储在数据库中-我认为这是从数据库继承用户类的正确方法-可能是重复的-这并不完全合适，但基本上它包含了您想要google的术语，特别是ActiveRecord。在应用程序中使用该模式是好还是坏的想法都无法从您提供的信息中得到答案。总的来说，它有一些问题。在实践中，它是有效的。我想这就是我现在正在做的，但不确定这是否是最好的方法。我当前创建了一个用户对象，并将DB连接详细信息传递给它。然后构造调用父构造并建立连接-这就是你的意思吗？对不起-再次阅读你的帖子，因为我误解了。因此，考虑到您所说的，如果我继续创建其他类，会发生什么？如果它们都连接到一个数据库，这将是不理想的，是吗？？？您将向需要连接的任何人传递相同的（已经构建的）db对象实例。在一个单独的请求中，当然。添加了轻代码示例。接口用于抽象，但对于概念来说不是必需的。这绝对是一条路要走。每个类都应该有单独的责任，如果它们需要一起工作，应该使用依赖注入进行组合。将不得不研究抽象类。谢谢你的回答-我有点担心全局类，因为很多人似乎都在警告它们。我采用上面的Nathans方法，将一个db对象传递给用户构造函数。这似乎很管用！我可以问一下吗？在您的第一个代码示例中，我注意到您有$username和$password参数以及$db对象参数。为什么要使用$user/$pass对象，因为在您创建数据库对象时，连接肯定已经建立好了？很抱歉造成混淆$构造函数中的用户名和$password不是用于数据库的，而是用户对象中用户的用户名和密码。我只是假设您将使用用户的用户名和密码实例化用户对象以进行身份验证。哦，好的-这就引出了这个问题。。。您的用户类中是否真的有一个方法可以向数据库注册/添加用户，因为显然没有用户名/