Simple is better than complex. Complex is better than complicated.

Menu

Zend Framework DAL: DAOs and DataMappers

A Data Access Layer (DAL) is the layer of your application that provides simplified access to data stored in persistent storage of some kind. For example, the DAL might return a reference to an object complete with its attributes instead of a row of fields from a database table.

A Data Access Objects (DAO) is used to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data. Also, it implements the access mechanism required to work with the data source. The data source could be a persistent store like a database, a file or a Web service.

And finally, the DataMapper pattern is used to move data between the object and a database while keeping them independent of each other. The DataMapper main responsibility is to transfer data between the two and also to isolate them from each other.

Here’s an example of the DataMapper pattern:

Database Table Structure

The User DAO

The DAO pattern provides a simple, consistent API for data access that does not require knowledge of an ORM interface. DAO does not just apply to simple mappings of one object to one relational table, but also allows complex queries to be performed and allows for stored procedures and database views to be mapped into data structures.

The User Repository

Repositories play an important part in DDD, they speak the language of the domain and act as mediators between the domain and data mapping layers. They provide a common language to all team members by translating technical terminology into business terminology.

Lets create a UserRepository class to isolate the domain object from details of the DAO:

16 thoughts on “Zend Framework DAL: DAOs and DataMappers”

Hi Federico,
Zend_Entity and Doctrine 2 are in-development and will be generic DataMapper implementation driven by annotation or yaml/xml metadata, like Hibernate for Java. I started to contribute to both and their objective is also to eliminate the requirement for custom classes, speeding up development.

Yes, I’m following the development of ZF and Doctrine very closely. I like Benjamin’s proposal (http://bit.ly/JrSM6), and it’s great that Zend is supporting it and that you are helping him. I’m glad Zend finally decided to adopt these design patterns that have proven to increase the efficiency of the coding process.

I think there is something that doesn’t quite feel right with your code. The idea of working with DAL’s is a great idea, but I think that your implementation is still too tightly coupled to the Db:

In your Project_Model_User, you get an instance from the Db. But the problem is that when you want to change your persistance from Db to let’s say Soap, you have to change all your models, because they’re now coupled to the Db.

Models should not have to know where their data comes from. Well actually, they should: from your Datamapper. So it seems more logical, to let the Datamapper care about which DAO should be used.

Only issues I spot there are composite primary key mapping problems (always gets the last one instead native primary key) and some Flex/AMF incompatibilities (returned arrays are empty and need recast).

While implementing this DataMapper pattern in my project, I was thinking that we’re using the DataMappers to abstract away the DAOs from the models – so that we can swap a DAO whenever we need (say for caching). However, we have to keep the interface of the DAOs same so that the mapper can work with it without knowing anything about the implementation details – it just needs to know the functions that are same across all the DAO implementations.

Now, how about using a Factory to do the same? As the DAOs are implementing the same interface, models need not to know more details about their inner implementation. Consider the following code (written in Project_Model_User:

What I’m doing is passing a Loader (Factory) and Injector to the ORM Manager, who’s responsible for loading the DataMapper and injecting dependencies. I’m not using a Locator class, but you can use one if you want, I guess it depends on the directory structure of your project.

I was looking for good code examples using both DAO and repositories and fell over your site. I don’t use Zend (or PHP for that matter) so excuse me if I have misunderstood something.

You are giving a simple and great overview of the different responsibilities, I did however not like the line:
$this->setDatabaseDao(new UserDatabaseDao());

Here you’re coupling the repository layer directly with the DAO implementation. This is perhaps also what Emran is saying, but on C# I would use some kind of “inversion of control container” for this. Injecting the given implementation into the class through your repository constructor.

If this is not possible in Zend, I would the very least put the instantation of the DAO classes in some factory to keep all the coupling to specific DAO classes in one place.