in Zend, Why do We use DB Model class and Mapper class as two separate?

Question

I am working on the zend project, I am referring on other zend project to create the new Zend Project.But I don't like to blindly follow that project without understanding. In the Zend Directory structure, In Model class there are mainly two type of classes I see, like 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 this specific structure is followed? Is this is to separate Object class and Database model class?

Please explain.

Hamiltonian

In short: Yes. What do you expect as answer? (sidenote: when Blog has methods save() and such, it's more an active-record implementation and less a model in the meaning of the model-mapper-concept) – Kylakylah

@KingCrunch, I want to know that why this is structure is used? Can't we directly use one class to store values in data base? I have just started up with zend, that is wny. Dont know reason about this pattern? – Hamiltonian

I didn't read the answers, thus I guess it's answered somewhere there. The short reason is just: Separation of business- and data-access-logic. – Kylakylah

Answer 1

DataMapper is a design pattern from Patterns of Enterprise Application Architecture.

The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema.

How you store data in a relational database is usually different from how you would structure objects in memory. For instance, an object will have an array with other objects, while in a database, your table will have a foreign key to another table instead. Because of the object-relational impedance mismatch, you use a mediating layer between the domain object and the database. This way, you can evolve both without affecting the other.

Separating the Mapping responsibility in its own layer is also more closely following the Single Responsibility Principle. Your objects dont need to know about the DB logic and vice versa. This gives you greater flexibility when writing your code.

When you dont want to use a Domain Model, you usually dont need DataMapper. If your database tables are simple, you might be better off with a TableModule and TableDataGateway or even just ActiveRecord.

For various other patterns see my answer to

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

Leola

Answer 2

The idea of a Model is to wrap up the logical collection of data inside of your code.

The idea of a DataMapper is to relate this application-level collection of data with how you are storing it.

For a lot of ActiveRecord implementations, the framework does not provide this separation of intent and this can lead to problems. For example, a BlogPost model can wrap up the basic information of a blog post like

• title
• author
• body
• date_posted

But maybe you also want to have it contain something like:

• number_of_reads
• number_of_likes

Now you could store all of this data in a single MySQL table to begin with, but as your blog grows and you become super famous, you find out that your statistics data is taking an awful lot of hits and you want to move it off to a separate database server.

How would you go about migrating those fields of the BlogPost objects off to a different data store without changing your application code?

With the DataMapper, you can modify the way the object is saved to the database(s) and the way it is loaded from the database(s). This lets you tweak the storage mechanism without having to change the actual collection of information that your application relies on.

Bresnahan