php - zf2 - zend framework db limit

Zend Framework gateway de datos de tabla estilo ORM vs. Zend_Db_Table_Abstract

Question

En Zend Framework Quickstart , ha habido un cambio en los modelos que extienden Zend_Db_Table_Abstract al patrón Table Data Gateway.

Personalmente, no he tenido mucha experiencia con este patrón y sigo oyendo que esto probablemente debería usarse en lugar de hacerlo a la manera antigua.

Un breve ejemplo del inicio rápido:

Vieja forma:

class Default_Model_Guestbook extends Zend_Db_Table_Abstract
{
protected $_name = ''tablename'';
// do stuff
}

Nueva manera:

// The actual model
class Default_Model_Guestbook
{
protected $_comment;
protected $_created;
protected $_poster;
// list continues with all columns
}
// Dbtable for this model
class Default_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract
{
/** Table name */
protected $_name = ''guestbook'';
}
// Mapper
class Default_Model_GuestbookMapper
{
public function save($model);
public function find($id, $model);
public function fetchAll();
}

De mi falta de experiencia con este estilo de programación, me resulta difícil comprender los beneficios reales de esta última manera; Entiendo que este método separe la base de datos de la lógica real tanto como sea posible, lo que en teoría debería facilitar la transición a otra plataforma de base de datos. Sin embargo, realmente no veo que esto ocurra en ningún proyecto en el que esté trabajando.

Casi no hay duda de que estoy pasando por alto algo, así que me encantaría escuchar sus consejos.

La pregunta:

• ¿Podría alguien explicarme por qué (o si) la última es una mejor práctica?

• ¿Debo cambiar de la forma antigua a la nueva o sigo habiendo razones adecuadas para seguir con los modelos que representan las tablas de la base de datos?

Gracias por adelantado.

Answer 1

Aquí está mi explicación de por qué esta es una mejor práctica:

Creo que el beneficio real de esto es la capacidad de cambiar sin problemas tus fuentes de datos. Al agregar una capa adicional de abstracción en su aplicación, sus modelos ya no representan una tabla de base de datos (nunca debería tener, en mi opinión) ya que un modelo debería ser una representación de los datos (no una puerta de enlace). La capa de acceso a la base de datos debe ser encapsulada por el modelo, lo que le permite más flexibilidad.

Digamos, por ejemplo, que su aplicación debe comenzar a usar un servicio SOAP o XML-RPC como fuente de datos / almacenamiento. Al utilizar el enfoque del correlacionador de datos, tiene una clara ventaja, ya que cuenta con la estructura necesaria para agregar estas interfaces de capa de datos específicas sin demasiada (si existe) interferencia con sus modelos existentes.

¿Deberías hacerlo, sin embargo? Esa es una pregunta pragmática. Personalmente, me gusta tener la tranquilidad de saber que estoy desarrollando algo que es flexible y que sigue las mejores prácticas (acordadas). Sin embargo, solo usted sabe si la creación de una aplicación más flexible facilitará sus proyectos, ya sea ahora o en el futuro, para crear y mantener.

Para mí, me gusta la sensación de que estoy creando algo, considero que es la mejor práctica y, a menudo, rinde dividendos.

Answer 2

Es útil porque puede hacer $insert = new Model_Guestbook($param1, $param2, $param3); - Significa que cuando alguien llega al proyecto, puede crear una nueva instancia fácilmente sin tener conocimiento de la estructura de la base de datos (verificando la interfaz fuente / modelo). Este es solo uno de los beneficios que ofrece este método :)