Is it a good idea to put all database related methods into one class? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

Would it be a better design to put all the database communication into one class or use it accross the whole program?

Answer 1

It's a good idea to follow Single responsibility principle (SRP), so you could have well defined roles/responsibilities for your classes. Don't have a class doing too many things.

Also consider Separation of concerns which simply put, is about having a clear separation between different parts of the application, such as templates, data and logic.

You can have a data/model layer that deals with the data of your application, without getting in the way of logic.

For example, have a DataMapper class for different entities in the system. The DataMapper could be responsible for interfacing with the database, pulling data, inserting and updating. This would be where the SQL lives, or the code to deal with some other storage mechanism if it didn't happen to be MySQL.

The benefit of this is in your logic code, you don't clutter it up with SQL statements all over the place, you simply call the DataMapper.

Quick example:

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

Note how the database object is passed to the mapper, this is Dependency Injection.

• Martin Fowler - Data Mapper

Answer 2

It's always better to use the "DRY" (Don't Repeat Yourself) principle and keep the code in one place. But I think what you are asking comes down to being pragmatic. If you take a look at php frameworks, they typically use the adapter pattern [1] to wrap something like pdo(a database driver) in a class and then use that class in the framework. This buys you the option to swap out the PDO driver for another at a later date without altering the code that depends on the database class. Now this sounds great, and it is. But that is a lot of extra work to wrap the PDO/database driver class and if I were going to do something like that, I'd ask myself why not just use a framework that has already done this for me. Also, PDO is already a wrapper for different database drivers (mysql, postgre, etc.). So, you're kind of wrapping a wrapper at that point. I think if it were me, I'm okay with relying on PDO for a 'roll-your-own' project because it still allows me to switch out the driver and just call that throughout my application. I still think that a better solution is to use a framework and really learn it well. Study the internals and then study why they did things the way they did. What I absolutely would not do is sprinkle random sql throughout my classes because at that point, you have no recourse if you need to change databases.

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

Answer 3

There are many approaches which try to solve this issue.

One approach is to create a repository class for each of your domain objects, for example if there are users in your application then you would create a UserRepository class, if there are articles in your application then you would create a ArticleRepository class etc. The UserRepository class could look like this:

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

    public function findAll(){
        // Implementation
    }

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

It is common practice to have one BaseRepository class which contains methods common for all repository classes, typically basic CRUD operations:

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

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

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

class UserRepository extends BaseRepository {
    // User specific methods
}