En Zend, ¿por qué utilizamos la clase de modelo DB y la clase Mapper como dos separadas?

Question

Estoy trabajando en el proyecto Zend, me refiero a otro proyecto Zend para crear el nuevo proyecto Zend. Pero no me gusta seguir a ciegamente ese proyecto sin comprender. En la estructura del directorio de Zend, en la clase de modelo hay principalmente dos tipos de clases que veo, como como en

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

¿Por qué se sigue esta estructura específica? ¿Es esto para separar la clase de objetos y la clase de modelo de base de datos?

Por favor explique.

Answer 1

DataMapper es un patrón de diseño de patrones de arquitectura de aplicaciones empresariales.

El mapeador de datos es una capa de software que separa los objetos en memoria de la base de datos. Su responsabilidad es transferir datos entre los dos y también aislarlos el uno del otro. Con el mapeador de datos, los objetos en memoria no necesitan saber ni siquiera que haya una base de datos presente; No necesitan código de interfaz SQL, y ciertamente no hay conocimiento del esquema de la base de datos.

La forma en que almacena datos en una base de datos relacional suele ser diferente de cómo estructuraría los objetos en la memoria. Por ejemplo, un objeto tendrá una matriz con otros objetos, mientras que en una base de datos, su tabla tendrá una clave extranjera para otra tabla. Por el desajuste de impedancia relacional de objetos, Utiliza una capa de mediación entre el objeto de dominio y la base de datos. De esta manera, puede evolucionar ambos sin afectar al otro.

Separar la responsabilidad de mapeo en su propia capa también sigue más de cerca el Principio de responsabilidad única. Sus objetos no necesitan saber sobre la lógica de DB y viceversa. Esto le brinda una mayor flexibilidad al escribir su código.

Cuando no desea usar un modelo de dominio, generalmente no necesita DataMapper. Si las tablas de su base de datos son simples, puede estar mejor con un TableModule y TabledAtagateway o incluso solo Activerecord.

Para varios otros patrones, vea mi respuesta a

• ORM/DAO/DATAMAPPER/Activerecord/TableGateway ¿Diferencias? y
• http://martinfowler.com/eaacatalog/index.html

Answer 2

La idea de un modelo es concluir la recopilación lógica de datos dentro de su código.

La idea de un DataMapper es relacionar esta recopilación de datos a nivel de aplicación con la forma en que lo está almacenando.

Para muchas implementaciones de Activerecord, el marco no proporciona esta separación de la intención y esto puede conducir a problemas. Por ejemplo, un modelo de blog puede concluir la información básica de una publicación de blog como

• título
• autor
• cuerpo
• Fecha de publicación

Pero tal vez también quieras que contengan algo como:

• número_of_reads
• número_of_likes

Ahora podría almacenar todos estos datos en una sola tabla MySQL para empezar, pero a medida que su blog crece y se vuelve súper famoso, descubre que sus datos de estadísticas están tomando un montón de éxitos y desea moverse a un servidor de base de datos separado.

¿Cómo haría para migrar esos campos de los objetos de BlogPost a un almacén de datos diferente sin cambiar su código de aplicación?

Con DataMapper, puede modificar la forma en que el objeto se guarda en la (s) base (s) de datos y la forma en que se carga desde la (s) base (s) de datos. Esto le permite ajustar el mecanismo de almacenamiento sin tener que cambiar la recopilación real de información en la que se basa su aplicación.