php - ventajas - Diferencia entre la capa de acceso a datos y el modelo en MVC

mvc php

Question

Implementé lo que pensé que era una representación bastante buena de MVC en varias aplicaciones web, pero desde que me uní al crackoverflow, descubrí que tal vez mis definiciones iniciales eran un tanto simplistas y por eso realmente me gustaría aclarar las diferencias entre Capa de acceso a datos y el modelo o capa de dominio de una aplicación web.

Por contexto, actualmente utilizo objetos de acceso a datos que implementan las funciones CRUD para un solo registro en la tabla que el objeto representa, así como una función get () que devuelve un objeto que me permite iterar a través de todos los objetos que cumplen con el criterios para la función get ().

Estos objetos de acceso a datos se referencian directamente desde los scripts del controlador que contienen mi lógica comercial.

Si importa, estoy trabajando en PHP y MySQL, pero estoy interesado en sugerencias que podrían estar codificadas en otros idiomas.

ACTUALIZACIÓN: Para un ejemplo más específico, tengo una tabla llamada usuario (la convención aquí es nombres de tabla singulares) que contiene información como dirección de correo electrónico, estado activo, nombre de usuario, contraseña, a qué compañía pertenecen, etc. Este objeto básico sería mira esto en el código:

class User implements DataAccessObject
{
protected $user_id;
protected $email;
protected $username;
protected $password;
protected $company_id;
protected $active // Bool that holds either a 0 or 1
public function __construct ( $user_id ) // Uses Primary Key to know which record to construct
{
$sql = //Sql to get this information from the database.
// Code necessary to assign member variables their values from the query.
}
public function insert(){}
public function update(){}
public function delete(){}
public static function get($filters, $orderVals, $limit){}
// An object such as user might also contain the following function definition
public static function login($username, $password){}
}

Suena como si hubiera bastardeado la capa DAO Layer and Model en una forma simplificada que combina ambas funciones tipo de mundo real (como inicio de sesión para un usuario) con las funciones de acceso a datos.

Answer 1

Las clases modelo son independientes como un modelo bueno, limpio y de alta fidelidad de las entidades del mundo real. Si se trata de un dominio comercial, pueden ser clientes, planes, productos, pagos, todo ese tipo de cosas. Tu aplicación funciona con estas clases. La idea es que su aplicación sea un modelo del manejo de los objetos de dominio en el mundo real. Su aplicación puede tener funciones de método que parecen verbos que la gente realmente hace, y la implementación de esas funciones de método parece una descripción del mundo real de objetos del mundo real.

Importante: Esto es (idealmente) independiente de la mayoría de las consideraciones técnicas. Es el modelo más puro de los objetos de dominio que puede definir. [Sí, tiene problemas de búsqueda de claves externas, y sí, tiene que hacer que los objetos de su modelo conozcan algunos componentes de acceso a los datos para que un objeto modelo pueda encontrar entre sí objetos dados solo con claves externas en lugar del objeto real. Una buena capa de ORM maneja este problema de navegación para usted.]

Un modelo lleno de SQL no es un buen modelo. El mundo real tampoco está lleno de SQL. Una factura es un documento con algunos nombres y direcciones y artículos, y una fecha de envío, y un montón de cosas así.

Las clases de acceso manejan el almacenamiento persistente. Por lo general, esto incluye asignar los objetos de su modelo a tablas de bases de datos relacionales. Una capa de acceso a datos orientada a SQL reconstruiría su modelo a partir de una base de datos relacional y persistiría su modelo en una base de datos relacional. Una capa de acceso a datos YAML leería y escribiría archivos YAML de su modelo.

Algunas veces, el patrón de diseño mapeo relacional de objetos (ORM) se usa para hacer una separación limpia entre el mundo de SQL y su modelo. En ocasiones, un objeto de acceso a datos (DAO) maneja esta separación entre SQL y modelo. Un objeto ORM o DAO se puede empaquetar lleno de SQL.

De hecho, cuando cambia los productos de la base de datos, el único cambio está en DAO o ORM. El modelo nunca cambia, porque es independiente de SQL, YAML, JSON, XML o alguna otra técnica de serialización.

Si su DAO crea y persiste objetos del modelo, creo que tiene las partes del modelo de MVC implementadas razonablemente bien. Puede consultar los paquetes ORM para obtener ideas adicionales del estado del arte. Soy un fan de iBatis , yo mismo.

Pero es solo 1/3 de toda la visión del mundo de MVC. Y, por supuesto, los puristas le dirán que MVC es solo de escritorio o solo smalltalk o diferente de la implementación web común de MVC.

Answer 2

Es solo una cuestión de mayor abstracción. Si piensa en algún problema comercial que está a punto de resolver, quiere pensarlo en términos de conceptos (entidades, relaciones, procesos, etc.) de ese negocio, no en términos de objetos de base de datos o en un nivel más detallado, en términos de las partes internas de algún sistema de base de datos específico (por ejemplo, MySQL). De esta manera, puede modelar el dominio (es decir, el negocio y sus reglas) de forma independiente en la tecnología particular que utiliza para la implementación.

En otras palabras, cuando hablas "data-access-layerish" hablas de tablas, filas, tipos de datos o incluso acerca de los enfoques para acceder a estos datos (por ejemplo, usando el patrón de registro activo) mientras que cuando hablas de dominio, hablar sobre objetos comerciales, reglas comerciales y procesos comerciales.

Y, dicho sea de paso, al usar el patrón MVC, debe encapsular la lógica comercial en el nivel de su modelo (dominio) (como dije antes), no en los controladores: deberían desencadenar esas reglas, por así decirlo.