¿Debo separar totalmente los modelos y ORM en MVC?

Question

Estoy trabajando en una aplicación MVC en PHP que no utiliza ningún framework. Estoy usando RedBean para mi ORM, que implementa el patrón de mapeo de datos y funciona bastante similar al doctrine.

Según este question, entiendo que el modelo NO es el objeto ORM. En mi proyecto tengo los siguientes escenarios:

• Modelos "complicado" que deben hablar con un montón de tablas en la base de datos:

  • Uno de estos modelos puede ser algo como los permisos de RBAC sistema. Un controlador debe poder llamar a algo como $permission->isAllowed($controller, $action, $resource) para determinar si el usuario puede realizar la acción solicitada. Además, puede llamar al $permission->getPermissions() para obtener una lista de los permisos que tiene el usuario.

• modelos "simple" donde el modelo generalmente se puede representar por 1 tabla en la base de datos:

  • Uno de estos modelos serían el modelo User. Por ejemplo $user->changeRank(), $user->addPoints() y así sucesivamente.

El problema que estoy enfrentando ahora es que mirar más documentación para diversos marcos, puedo ver que en los ejemplos, las conversaciones controlador con el ORM directamente. Por ejemplo, he aquí un ejemplo, el controlador de symfony2:

public function createAction() 
{ 
    $product = new Product(); 
    $product->setName('A Foo Bar'); 
    $product->setPrice('19.99'); 
    $product->setDescription('Lorem ipsum dolor'); 

    $em = $this->getDoctrine()->getEntityManager(); 
    $em->persist($product); 
    $em->flush(); 

    return new Response('Created product id '.$product->getId()); 
} 

Si un ORM no es el modelo, ¿por qué se permitió que el controlador de interactuar directamente con él? ¿No debería interactuar con un modelo que se parece a esto?

class ProductModel{ 
    public function newProduct($name, $price, $description){ 
     $product = new Product(); 
     $product->setName('A Foo Bar'); 
     $product->setPrice('19.99'); 
     $product->setDescription('Lorem ipsum dolor'); 

     $em = $this->getDoctrine()->getEntityManager(); 
     $em->persist($product); 
     $em->flush(); 
    } 
} 

Finalmente, describí el modelo permissions anteriormente. ¿Se considera que esto es un modelo en el contexto de MVC? Esta clase se usará en toda la aplicación, ya que la mayoría de las abcisiones deberán verificar los permisos de acceso.

Answer 1

Se utiliza un ORM (Object Relational Mapper) para generar archivos de modelo. Los archivos de modelo se utilizan para comunicarse entre la aplicación y la base de datos (modelo). Parece que usted es versado en los procesos de ORM, pero un rápido recapitulación (utilizando la doctrina como ejemplo), para aquellos que no lo son, y podría tener suerte y responder a su pregunta.

Utiliza el ORM para introspectar su esquema de base de datos, que genera un archivo de esquema. Ahora, con este archivo de esquema, puede modificarlo para adaptarlo a las necesidades de su aplicación. Por ejemplo, puede agregar actAs: { Timestampable ~} o actAs: NestedSet: hasManyRoots: true. Además, querrá usar este archivo de esquema para configurar cómo quiere que se comporten las relaciones entre los objetos (es decir, 1: M, M: M usando refClass, etc.)

Una vez que su archivo de esquema esté listo, usted emita el comando para generar los archivos de modelo. Los archivos modelo son clases que puede usar dentro de su aplicación para obtener acceso a la base de datos. Entonces el controlador se está comunicando con el modelo (su base de datos) a través de los archivos generados por el ORM.

El ejemplo que dio es bueno, ya que puede descargar gran parte de la lógica de negocio de su acción (controlador de página) y en su modelo. De esta forma, se puede acceder a la misma lógica desde otros puntos de código sin tener que lidiar con ninguna lógica de nivel de controlador. Lo que hace la doctrina (y lo hace también) es permitirle crear clases 'Table' (o 'Peer'). Estas clases actúan como contenedores para tratar con múltiples objetos. Dentro de estas clases debe agregar su lógica comercial como lo demostró en su segundo ejemplo.

El objetivo final es mantener sus acciones lo más livianas posible, solo con parámetros de solicitud y manejo de formularios, luego aplique los valores a su modelo a través de 'Table' o las clases personalizadas que diseñe. Siguiendo este paradigma, puede tener una aplicación rica en características con acciones de recorte y lógica de negocios centralizada.

Editar ---

En este momento no vi a su última pregunta respecto a su API de autorización. Según lo que publicaste, parece seguir el paradigma MVC en el sentido de que tienes un objeto de permiso y lo estás utilizando como una API entre el controlador y la base de datos.