PATRONES DE DISEÑO - MVC

Modelo-Vista-Controlador (Model-View-Controller MVC)

1. EJEMPLO YII

Yii implementa el diseño de patron modelo-vista controlador (model-view-controller MVC) el cual es adoptado ampliamente en la programación Web. MVC tiene por objeto separar la lógica del negocio de las consideraciones de la interfaz de usuario para que los desarrolladores puedan modificar cada parte más fácilmente sin afectar a la otra. En MVC el modelo representa la información (los datos) y las reglas del negocio; la vista contiene elementos de la interfaz de usuario como textos, formularios de entrada; y el controlador administra la comunicación entre la vista y el modelo.

Más alla del MVC, Yii tambien introduce un front-controller llamado aplicación el cual representa el contexto de ejecución del procesamiento del pedido. La aplicación resuelve el pedido del usuario y la dispara al controlador apropiado para tratamiento futuro.

El siguiente diagrama muestra la estructura estática de una aplicación Yii"

Estructura estática de aplicación Yii

1. Un flujo de tareas típico 

El siguiente diagrama muestra un típico flujo de tareas de una aplicación Yii cuando resuelve un pedido de usuario:

Un típico flujo de tareas de una aplicación Yii

1. Un usuario realiza un pedido con la siguiente URL http://www.example.com/index.php?r=post/show&id=1 y el servidor Web se encarga de la solicitud mediante la ejecución del script de arranque en index.php.
2. El script de entrada crea una instancia de applicación y la ejecuta.
3. La aplicación obtiene la información detallada del pedido del usuario del componente de aplicaciónrequest.
4. El controlador determina le controlador y la acción pedido con ayuda del componente de aplicación llamado urlManager. Para este ejemplo el controlador es post que refiere a la clase PostController y la acción es show que su significado es determinado por el controlador.
5. La aplicación crea una instancia del controlador pedido para resolver el pedido del usuario. El controlador determina que la acción show refiere al nombre de método actionShow en la clase controlador. Entonces crea y ejecuta los filtros asociados con esta acción (ejemplo: control de acceso, benchmarking). La acción es ejecutado si los filtros lo permiten.
6. La acción lee el modelo Post cuyo ID es 1 de la base de datos.
7. La acción realiza la vista llamada show con el modelo Post
8. La vista lee y muestra los atributos del modelo Post.
9. La vista ejecuta algunos widgets.
10. El resultado realizado es embebido en un esquema (layout).
11. La acción completa la vista realizada y se la muestra al usuario.

----------------------------------------------------------------------------------------------------------------------

MVC está muerto, es hora de seguir adelante.

Conrad Irwin - Junio ​​2012

MVC es una idea fenomenal. Usted tiene modelos, que son agradables pedacitos independientes de Estado, vistas que son buenos pedacitos independientes de la interfaz de usuario y los controladores que son buenos pedacitos independientes de ...

¿Qué?

Ciertamente no soy la primera persona en darse cuenta de esto, pero el problema con MVC como se da es que usted termina el relleno demasiado código en los controladores, porque usted no sabe dónde más ponerlo.

Para solucionar este problema que he estado usando un nuevo patrón:MOVER . M odelos, O peraciones, V iews y E respiraderos.

Visión de conjunto

Voy a definir los detalles en un minuto, pero este diagrama muestra la estructura básica de una aplicación de MOVE.

• Modelos encapsular todo lo que su aplicación sabe.
• Operaciones encapsular todo lo que hace la aplicación.
• Vistas mediar entre la aplicación y el usuario.
• Los eventos se utilizan para unir todos estos componentes de manera segura.

Con el fin de evitar el código espagueti, también vale la pena señalar que hay recomendaciones para lo que se permiten los objetos de cada tipo de hacer. He representado a estos como flechas en el diagrama. Por ejemplo, las vistas se les permite escuchar a los eventos emitidos por los modelos, y las operaciones se les permite cambiar los modelos, pero los modelos no deben hacer referencia a puntos de vista o las operaciones.

Modelos

El modelo arquetípico es un objeto de "usuario". Tiene por lo menos una dirección de correo electrónico, y probablemente también un nombre y un número de teléfono.

En los modelos de aplicación de MOVE sólo envolver conocimiento. Esto significa que, además de los captadores y definidores, pueden contener funciones que le permiten comprobar "es la contraseña del usuario?", Pero que no contienen funciones que permiten guardarlos en una base de datos o subirlos a una API externa . Ese sería el empleo de una operación.

Operaciones

Una operación común para las aplicaciones está registrando un usuario pulg Es realmente dos sub-operaciones compuestas juntos: primero obtener la dirección de correo electrónico y la contraseña del usuario, segundo cargar el modelo "usuario" de la base de datos y comprobar si la contraseña coincide.

Las operaciones son los que hacen el mundo de MOVE. Ellos son responsables de hacer cambios a sus modelos, para mostrar los puntos de vista correctos en el momento adecuado, y para responder a los eventos provocados por las interacciones del usuario. En una aplicación bien factorizada, cada sub-operación se puede ejecutar de forma independiente de su matriz; por lo que en los hechos diagrama de flujo hacia arriba, y los cambios son empujados hacia abajo.

Lo que es interesante sobre el uso de las operaciones de esta manera es que toda la aplicación en sí puede ser tratada como una operación que se inicia cuando se inicia el programa. Se genera tantos sub-operaciones, ya que necesita, donde se ejecuta cada sub-operación concurrente existente en paralelo, y se sale del programa cuando todos están completos.

Vistas

La pantalla de inicio de sesión es una vista en la que se encarga de mostrar un par de cuadros de texto para el usuario. Cuando el usuario hace clic en el botón "login" la vista producirá un evento de "loginAttempt", que contiene el nombre de usuario y una contraseña que el usuario escribió.

Todo lo que el usuario puede ver o interactuar con debe ser alimentado por una vista. Ellos no sólo muestran el estado de la aplicación de una forma comprensible, pero también simplifican el flujo de las interacciones del usuario entrantes en eventos significativos. Es importante destacar que vistas no cambian modelos directamente, simplemente se emiten eventos a las operaciones, y esperar a que los cambios al escuchar a los eventos emitidos por los modelos.

Eventos

El evento "loginAttempt" se emite por la vista cuando el usuario hace clic identificarte. Además, cuando la operación de inicio de sesión se completa, el modelo de "currentUser" emitirá un evento para notificar a la aplicación que ha cambiado.

Escuchando en eventos es lo que da de MOVE (y MVC) la inversión de control que usted necesita para permitir que los modelos para actualizar vistas sin los modelos de ser directamente conscientes de que las opiniones están poniendo al día. Esta es una poderosa técnica de abstracción, permitiendo que los componentes que se acoplan entre sí sin interferir entre sí.

¿Por qué ahora?

No quiero que se me malinterprete como dando a entender que MVC es malo; que realmente ha sido una manera increíblemente exitosa para estructurar grandes aplicaciones para las últimas décadas. Desde que se inventó, sin embargo, las nuevas técnicas de programación se han vuelto populares. Sin cierres (o bloques anónimos) de enlace de eventos puede ser muy tedioso; y sin deferrables (también conocidos como deferreds o promesas) la idea de tratar las operaciones individuales como objetos en sí mismos, no tiene mucho sentido.

Para reiterar: MVC es impresionante, pero está diseñado con décadas de antigüedad tecnologías. MOVE es simplemente una actualización para hacer un mejor uso de las nuevas herramientas que tenemos.