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.

Thanks for sharing…

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:


$dao = DaoFactory::create("Db");
$dao->setTable("users");
$user = $dao->find(13);


In a similar way, we can do the following, based on logic/settings:

$dao = DaoFactory::create("ZohoCloudDB");
$dao = DaoFactory::create("MyService");

What are the pros/cons of this approach? Any thoughts from anybody?

Thanks

The idea behind this post was to show how the Data Mapper pattern works independently of the Table Data Gateway pattern.

Thanks for your response and the code examples – things are clearer now.

I was checking the ZF quick-start tutorial on this URL: http://framework.zend.com/docs/quickstart/create-a-model-and-database-table. It shows an integration between the Domain Entity and the Domain Model.

Although to my eyes it seems to be pretty much the same, but do you see any foreseeable problem with that approach? Your comment would be appreciated.

Thanks

Emran

Q #1:
http://fedecarg.codepad.org/Uq9ihiSj

Q #2:
http://codepad.org/v8cj85Mk (clone the entity object)

Great post with nice examples. I’m going to follow this in one of my projects soon and a few question struck me. Thought I’d share here.

I am curious about a scenario where a record retrieval depends on sub records. For example, let’s say we store multiple addresses for each user as follows:


CREATE TABLE `address` (
`id` int(11) NOT NULL auto_increment,
`user_id` int(11) NOT NULL,
`street` varchar(100) NULL,
`city` varchar(100) NULL,
`state` varchar(100) NULL,
PRIMARY KEY (`id`)
)


Now, when I use $user->getAddresses() function from controller, I expect to receive the addresses associated with this user entity. How should this be handled – in the Entity and Mapper ?

Another question of mine, when we are doing dependency injection as the following code:


$mapper = new Project_DataMapper_User();
$mapper->setEntity(new Project_Entity_User());
$user = $mapper->get($id);


How should I return multiple instance of the entity, for example in a $mapper->getBySomeCriteria function?

I appreciate any help and thanks in advance.

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).