Question

将所有数据库通信放入一个类或在整个程序中使用它会是一个更好的设计吗？

Answer 1

遵循Single responsibility principle (SRP)是一个好主意，因此您可以为您的班级定义明确的角色/职责。不要上课做太多事情。

另外考虑简单地说，Separation of concerns是关于在应用程序的不同部分之间进行明确分离，例如模板，数据和逻辑。

您可以拥有一个处理应用程序数据的数据/模型层，而不会妨碍逻辑。

例如，为系统中的不同实体提供DataMapper类。 DataMapper可以负责与数据库连接，提取数据，插入和更新。这就是SQL所在的地方，或者如果它不是MySQL那么处理其他存储机制的代码。

这样做的好处在于您的逻辑代码，您不会在任何地方使用SQL语句将其混乱，只需调用DataMapper即可。

快速举例：

$userMapper = new UserMapper($db);
$users = $userMapper->getAll();

注意数据库对象如何传递给映射器，这是依赖注入。

Martin Fowler - Data Mapper

Answer 2

最好使用“DRY”（不要重复自己）原则并将代码保存在一个地方。但我认为你所要求的归结为务实。如果你看看php框架，他们通常使用适配器模式[1]在类中包装类似pdo（数据库驱动程序）的东西，然后在框架中使用该类。这样就可以选择在以后更换另一个PDO驱动程序，而无需更改依赖于数据库类的代码。现在这听起来很棒，而且确实如此。但是，包装PDO /数据库驱动程序类需要做很多额外的工作，如果我要做类似的事情，我会问自己为什么不使用已经为我做过的框架。此外，PDO已经是不同数据库驱动程序（mysql，postgre等）的包装器。所以，你就是在那个时候包装一个包装器。我想如果是我，我可以依靠PDO来实现“自己滚动”项目，因为它仍然允许我切换驱动程序并在我的应用程序中调用它。我仍然认为更好的解决方案是使用框架并真正学习它。研究内部结构然后研究他们为什么按照他们的方式做事。我绝对不会做的是在我的课程中随机播放sql，因为在那时，如果你需要更改数据库，你就没有办法。

[1] http://en.wikipedia.org/wiki/Adapter_pattern

Answer 3

有许多方法试图解决这个问题。

一种方法是为每个域对象创建一个存储库类，例如，如果您的应用程序中有用户，那么您将创建一个UserRepository类，如果您的应用程序中有文章，那么您将创建一个ArticleRepository类等UserRepository类可能如下所示：

class UserRepository  {
    public function find($id){
        // Implementation
    }

    public function findAll(){
        // Implementation
    }

    public function findBy(array $criteria){
        // Implementation           
    }       
}

通常的做法是拥有一个BaseRepository类，其中包含所有存储库类的通用方法，通常是基本的CRUD操作：

class BaseRepository {
    public function create($object){
        // Implementation   
    }

    public function update($object){
        // Implementation       
    }

    public function delete($object){
        // Implementation
    }       
}

class UserRepository extends BaseRepository {
    // User specific methods
}

将所有与数据库相关的方法放在一个类中是一个好主意吗？

3 个答案: