Question

从C＃/ C ++迁移到PHP OOP已经证明有点问题，因为我不确定以相同的方式设计代码布局是标准的。在这种情况下，我很好奇以下在PHP方面是否会被认为是有问题或错误的。

CDeviceManager类（1已启动）
CDevice类
在CDeviceManager类中保留CDevice的私有数组
使用公共方法获取设备，搜索设备等。

然而，最棘手的问题是从MySQL数据库填充每个CDevice。将我的Database类直接包含在CDeviceManager中并在CDeviceManager Construct中填充CDevice数组是否安全？

我所阅读的很多内容都表明，将业务逻辑与视图分开是明智的，我觉得这种方法就是这样做的。我没有看到很多其他似乎使用这种方法的项目，为什么我担心我可能会遗漏一些东西。

Answer 1

最好将业务逻辑与数据存储系统分开。我建议使用依赖注入来完成工作。确切的实现将取决于您的需求（和项目规模），但是为了得到一个想法，这将是我会做的：

class CDeviceManager
{
    private $db;  //holder for your database
    private $cdevices = array();
    //more properties here

    public function __construct(Database $db)
    {
         $this->db = $db; //database connection has now been injected into your class
    }

    //more methods here
}

然后在创建CDeviceManager对象时沿着该行的某处，您可以注入数据库连接。

$cdm = new CDeviceManager( new Database(...) );

您的Database类可能是PDO或MySQLi或您想要使用的任何数据库API的包装器。你也可以走得更远，让CDeviceManager实现某种与数据库中各种CRUD函数相关的接口。最好的部分是，您可以更轻松地测试这一点，因为现在您可以使用模拟/测试数据库交换数据库连接，这样您就不会无意中搞砸了生产数据库。

$cdm = new CDeviceManager( new MockDatabase(...) );

或

$testdb = new TestDatabase(...);
$cdm = new CDeviceManager( $testdb );

所以是的，最终将数据库连接与域模型分开是件好事。有些人建议更进一步，确保您的域模型通常对存储机制完全无知，这样您就可以在存储系统/持久层上保持灵活性。 E.g：

$cdm = new CDeviceManager( new FileRetriever() );  //Maybe you are storing stuff in a flat file

希望有助于清理一点。

对象的管理器类

1 个答案: