Controlador frente a modelo - Necesita explicación

Question

Estoy al principio de mi forma de "aprender MVC". Básicamente, no tengo grandes problemas con la programación orientada a objetos, sin embargo, hay un aspecto técnico que necesita aclaración. Parece que mi teoría no es lo suficientemente buena.

Actualmente, estoy usando marco KohanaPHP, versión 3.

Ejemplo situación: He un sitio web, donde el usuario puede enviar un artículo.

Así que tienen la estructura siguiente:

classes/ 
    /controllers/ 
     article.php 
    /models/ 
     articles.php 

Hasta aquí todo bien. No tengo problemas con los modelos que amplían Kohana_Model, pero no estoy seguro si estoy usando los modelos de forma correcta que usan ORM.

Básicamente cuando uso modelos que extienden Kohana_Model pondré todas las operaciones lógicas en el modelo. ¿Debo hacer lo mismo con los modelos que usan ORM? En muchos ejemplos a través de la red, vi controladores que realizaban operaciones lógicas en la entrada/datos del usuario desde la base de datos, lo cual es incorrecto en mi opinión.

Digamos que necesito obtener algunas filas de la base de datos para crear el método adecuado en el modelo y devolver el objeto. Creo que es correcto, ¿no?

Básicamente, todas las operaciones en la entrada/datos del usuario (seleccionar desde db, insertar en db, validación) Puse en los modelos. Esa es la forma en que entiendo el patrón de diseño de MVC. Los modelos deben ocuparse de todas las operaciones "mecánicas" y el controlador es solo un "puente" entre los modelos/vistas y es un motor "frontal".

¿Es un enfoque correcto?

Sé que podría ser una pregunta tonta para usuarios más avanzados; sin embargo, quiero aprender solo buenas prácticas. Si alguien puede ofrecer alguna aclaración, estaré encantado.

Answer 1

En términos breves, su modelo realiza todas las operaciones sobre los datos (ya sean entrantes, salientes, bases de datos, archivos ... datos), y su vista debería ocuparse de mostrar los datos. El controlador debe llamar a los métodos de modelo necesarios para que los datos estén listos para pasar a la vista. El controlador no debe realizar ningún cambio en los datos, pero debe probarlo para realizar las acciones necesarias de forma adecuada.

Espero que haya sido lo suficientemente claro, hágame saber si esto no aclara las cosas para usted.

Answer 2

No he trabajado con KohanaPHP, pero parece un Framework 'inspirado en los rieles'. En el mundo de los rieles, generalmente se considera la mejor práctica tener controladores delgados y modelos de grasa.

algunos antecedentes se puede encontrar en este viejo artículo de Jamis Buck http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model o en ésta en relación con cakephp http://gluei.com/blog/view/cakephp-best-practices-fat-models-and-skinny-controllers

Answer 3

La idea de separar la lógica de los datos es que los datos no contienen lógica, por lo que en sus modelos solo debería estar realmente desinfectando los datos.

Tome este ejemplo:

public class Articles extends MasterModelLayer 
{ 
    public function create($title,$text,$user_id = false) 
    { 
     if(!$user_id) 
     { 
      $user_id = get_guest_id(); 
     } 
     //Insert 
    } 
} 

Parece lógico legítimo en los modelos, pero a partir de ahora su aplicación debe ser capaz de permitir que los invitados a exponer artículos, o su defectuoso y necesita editar los modelos, los cuales a continuación, piso voluntad sus otras aplicaciones/áreas de su sitio

Tome este escenario:

tienes 2 sitios

• ComputerArticles.com
• CookingArticles.com

Ahora estos 2 dominios apuntan al mismo servidor, pero una aplicación particular en Kohona, ser no colocar cualquier lógica de dominio dentro de sus modelos su capaz de utilizar los modelos de ejemplo exactas a través de todos sus dominios.

Sus Métodos modelo debe aparecer así:

public class Articles extends MasterModelLayer 
{ 
    public function create($title,$text,$user_id) 
    { 
     $this->compile("articles",array($title,$text,$user_id))->insert(); 
    } 
} 

Y dentro de los controladores que deben poner toda su lógica como lógica dependerá del dominio.

Piense en sus Modelos como una API, donde tiene varios sitios que usan la misma API pero con una lógica diferente.

Espero que esto ayude.

Answer 4

Estas son las definiciones simples básicos de los términos - Visto: Las pantallas que se presentan a los usuarios Controlador: Un motor/marco que tenga en las solicitudes, determina quién lo maneja y los delegados de manera apropiada. Modelo: Esto básicamente le dice qué pantalla mostrar después de que algo así se haga en esta pantalla. Piénselo como un gráfico (dirigido). Los bordes que salen de un nodo son acciones y los nodos a los que se conectan son las siguientes pantallas basadas en esas acciones.

Así que un modelo básicamente incluye las acciones que el usuario hace en las pantallas y sus controladores de acción. El controlador simplemente llama a un controlador de acción correspondiente para una acción de usuario particular y el controlador de acción es responsable de hacer algo sensato con la solicitud entrante.

Ahora su pregunta. ¿A dónde va la lógica de negocios? Bueno, es el controlador de acción. O se abstrae en algún lugar al que a la gente le gusta llamar: capa de negocios. Pero de todos modos se desencadena desde los propios manejadores de acción.

Por lo tanto, técnicamente, la lógica comercial es parte de acciones que a su vez son parte del Modelo. Esto tiene sentido si lo piensas de esta manera: el controlador maneja la interacción del usuario y presenta las vistas basadas en el modelo (acciones + negocio).

** Errores tipográficos corregidos.