In general, there are several ways to handle CRUD-operations for db-persisted entities.

Active Record vs Data Mapper

An Active Record is the object-representation of a database row that contains domain logic and persistence logic. It’s the simplest form – and to avoid duplicated, boilerplate code you can use abstract base classes, traits/mixins or modular composition to define basic db-interactions in one place and have every active record use the methods provided. This is the wikipedia-entry on the active record pattern.

This pattern comes in handy because it’s quick and straightforward to implement. But it has some drawbacks. As you noted, it’s note separating concerns as well as alternatives and therefore is somewhat harder to reason about. When dealing only with basic objects for table-rows, containing only scalar values, and when done efficiently – the increase in conceptual complexity can be negligible.

This is one huge drawback, though – most interesting business-logic involves composite objects, for example sales documents with a header, lines and relational constraints (foreign keys). Unless you employ database-technology that can simply map both non-scalar values and relations, that makes relying on the active record-pattern for persistence-logic problematic… and even with such technology it has potential to be cumbersome.

If you are working with a relational database constrained to scalar values (for relevant intents and purposes) in the persistence of your domain objects, you need *some form of ORM – Object-Relational-Mapping. This can be achieved with the easy-to-use, easy-to-implement active record-pattern. In the PHP-world, Laravel‘s Eloquent ORM-tool does just that.

The main contender is the Data Mapper-pattern (Wiki), where mapping is handled by separate classes, like Repositories that can return individual objects, collections, or even composite objects – through repositories using other repositories, or by specifying operations, including joins on the basic stored data in the composition of objects in a single repository. This pattern is used by the doctrine ORM-tool (PHP, again).

The key to making this idea work elegantly and with minimal repeated effort is to maintain meta-data about the object and its relation to columns and rows in database tables explicit – including keys, field types and mapping to object properties. It’s possible to automate some parts or even the entirety of the production of code for such meta-data containing entities in database procedures or a specific application object, for example by using SHOW CREATE TABLE results – and/or reflection on classes.

But it’s also possible to build your own, domain-specific, lightweight version of such an ORM, too. I have implement the data-mapper pattern in one of my own projects. Using SHOW CREATE TABLE, results, I can quickly construct meta-data classes for every domain-class. Using abstract base classes or traits (in fact, I wrote two versions), I can quickly implement a repository for every domain-class that uses the meta-data class, implements persistence, relational-access and the identity map pattern in virtue of keeping a cache of fetched db-rows and being a single instance used in the construction of all classes needing db-access for the respective domain-object. In turn, all repositories are constructed with a basic wrapper on the PDO-Class, that allows for easy logging and implementation of the observer pattern (for example to keep dependent foreign entities current).

Though the initial effort for setup and configuration is certainly higher than with active records, the increased separation of concerns and flexibility is mostly worth it when your project exceeds a certain level of complexity.

A related concern – the Unit of Work:

In many cases, some interactions will affect multiple entities, including domain-entities with regard to their persisted data. Often, such access has to have transactional integrity – meaning that while a modification-cascade is unfinished, modifying operations on the involved entities must not be permitted. A way to handle this – and an important tool in any case, is the Unit of Work-pattern. On a basic level, the Unit of Work provides a way to keep track of which entities are ‘clean’ or ‘dirty’ and which are scheduled for insert, update, delete, modify.

Additional sources:

• MSDN – Peristence Patterns
• Sitepoint – Implementing the Unit of Work pattern
• Catalog of Patterns of Enterprise Application Architecture
• doctrine
• Eloquent

You could use the Template Method Pattern. Here is how.

Have an abstract class that will be the parent and define the way things are being loaded from the database.

Loading method will be an abstract method returning a generic value.

Connection string will be an abstract property.

Once you extend other classes from this parent class you can then define their own connection string as needed and implement the method for loading by returning their own specific value through the use of generics.

If there is a similarity in all of the subclasses on how things are being loaded from the database just push it up to the parent class.

If there are no similarities then separating them was a good idea in the first place because you are separating concerns and not merging them.

This also allows you to keep your codebase organized when other developers contributing since they would need to extend the parent class which has the loading template to be able to write their own loading implementation.

It also decouples your repository from the rest of the codebase because the rest of your codebase doesn’t have a clue as to which specific subclass is implementing the parent class that knows how to load stuff.