What would be a good DAO pattern for combining with Injection Dependency for the PHP framework?

Question

I am developing a dependency injection PHP framework. My data objects are injection components like any other.

I have an abstract DAO class that each model should extend, which has:

• basic crud methods
• DI container reference for creating objects

In short, it is

abstract class AbstractDao { protected $fields; protected $container; // This is the (injected) DI container, used to create instances. protected $driver; // The injected database driver (ie PDO) public function insert() { // Insert implementation // Insert current instance. } public function fetch($id) { // Fetch implementation // Fetches a row and sets fields on current instance } public function fetchAll() { // Performs a select * query on database driver // Iterates through results, and creates an instance // for each result using $container, like this: foreach ($results as $row) { // I can't just make $instances[] = new Something(), or all the // dependency injection thing would mess up. $instances[] = $this->container->get('someDao'); } return $instances; } // Other methods. } class Book extends AbstractDao { protected $fields = array('field', 'definition', 'goes', 'here',); // No special behaviour is needed, so we can keep default // abstract implementation without overriding. } 

My question is: each implementation of a data object (book, person, user, etc.) should extend the AbstractDao object , so it will carry the weight of $ driver and $ container. In addition, since the $ fields property is defined at the instance level, each data object will have its own, adding extra overhead.

I am afraid that when working with large data sets this solution can lead to a significant increase in performance. I know that objects will just be referenced, not cloned, but the overhead can be sadly high.

A few solutions that I mean

• using static methods that can reduce overhead subclasses
• don't make my Daos extend the aforementioned AbstractDao, which should become a kind of DaoProvider. In this case, for each method I have to go through in the instance (a thing that I don't really like)

None of those solutions that I don’t like so much ... at first I don’t like static things, because they conflict a bit with the whole idea of ​​injection. Secondly, I don't like the idea of ​​removing the dao subclass template.

Any good idea would be really appreciated, thanks.

=== EDIT ===

Another thing that came to my mind. What I do not like about the 2nd approach ("dao provider") is that the provider must perform operations with Dao fields (given values, set status, set isDirty, etc.), Therefore, the fields should be accessible from the outside. With the subclassical approach, you can keep protected or private.

=== / EDIT ===

Answer 1

I suggest you create a DAO interface that declares the behavior that a DAO implementation should perform. Now in each specific DAO implementation, you can define your instance fields $driver , $container and $fields .

After that, you may need to create an AbstractModel class that each particular model must extend so that your AbstractModel and specific models are "data accessible." The AbstractModel class will look like this:

 /* * an AbstractModel */ abstract class AbstractModel { protected $daoImpl; function __construct(DAOInterface $daoImpl) { $this->daoImpl = $daoImpl; } //some other functions that are common to concrete models } /* * a concrete model */ class Model extends AbstractModel { function findAll($params) { //You can use the $daoImpl of AbstractModel to perform a CRUD operation $this->daoImpl->findAll($params); } } 

Now, whenever you create a specific model, you enter a DAO implementation in the model class.

 //inject a DAOInterface implementation into Model $model = new Model(new DAOImpl()); $model->findAll($params); 

The advantage here is that you can drown out various DAO implementations during testing, and it may be convenient to use a DI container here. There is a similar code example that I created when I created my DI container a few days ago.

By the way, I don’t see the need to insert the $container object inside your AbstractDAO, why don’t you pass the object returned when the container property is called. Thus, you can use the hinting type to force the parameters of the object to be of a certain type and to encourage a fast-delay mechanism if an erroneous object is passed and it may also be useful for you to create a Config class to process your $driver data so that users can freely configure the driver, which they want to use for db.