In Zend, Why do we use the DB Model class and the Mapper class as two separate?

Question

I am working on a zend project, I mean another zend project to create a new Zend project. But I don’t like blindly following this project without understanding. In the Zend catalog structure in the Model class, there are mainly two types of classes that I see, for example, as in

- models - DbTables - Blog.php //Extends Zend_Db_Table_Abstract - Blog.php // Contains methods like validate() and save() - BlogMapper.php // Also Contains methods like validate(Blog b) & save(Blog b) 

Why is this particular structure respected? Does this separate the class of the Object class from the database class?

Please explain.

Answer 1

DataMapper is a design pattern from enterprise application architecture patterns .

Data Mapper is a software layer that separates objects in memory from the database. His duty is to transfer data between them, as well as isolate them from each other. With the Data Mapper, objects in memory do not even need to know that there is a database; they do not need the SQL interface code and, of course, do not know the database schema.

How you store data in a relational database is usually different than how you structure objects in memory. For example, an object will have an array with other objects, while in the database, instead, the table will have a foreign key for another table. Due to the mismatch of the object-relational impedance , you are using the intermediary level between the domain object and the database. Thus, you can evolve and not influence others.

Separation of responsibility for comparison at own level is also more closely connected with the principle of single responsibility . Your objects do not have to know about database logic and vice versa. This gives you great flexibility when writing code.

If you do not want to use a domain model, you usually do not need a DataMapper. If your database tables are simple, you might be better off with TableModule and TableDataGateway, or even with ActiveRecord.

For other templates, see my answer to

• differences ORM / DAO / DataMapper / ActiveRecord / TableGateway? and
• http://martinfowler.com/eaaCatalog/index.html

Answer 2

The idea of ​​the model is to complete the logical collection of data inside your code.

The idea behind DataMapper is to associate this dataset at the application level with how you store it.

For many ActiveRecord implementations, the framework does not provide this separation of intent, and this can lead to problems. For example, the BlogPost model can wrap basic blog information, such as

• title
• Author
• Body
• date_posted

But you might also want it to have something like:

• number_of_reads
• number_of_likes

Now you can save all this data in one MySQL table to start, but as your blog grows and you become super famous, you will find that your statistics capture many hits and you want to move it to a separate database server.

How could you transfer these fields of BlogPost objects to another data store without changing the application code?

Using DataMapper, you can change the way the object is saved to the database and the way it is loaded from the database. This allows you to customize the storage mechanism without having to change the actual set of information your application relies on.