model-view-controller - ventajas - mvc php
¿Cuál es la ventaja de Model-View-Controller(MVC) sobre Model-View? (3)
En MVC, el Modelo es ciego a su entorno, la vista también puede serlo, transmitiendo (ciegamente) sus eventos al controlador, que sabe más sobre la vista y el modelo. Entonces, cuando todo está dicho y hecho, el controlador es la parte desechable ''no reutilizable'' del sistema, ya que es el componente más sensible al contexto.
si cambié el modelo de una manera que afecta al controlador ...
El modelo debe exponer métodos CRUD sencillos de tal manera que aquellos que usan los métodos no tengan que saber nada sobre el objeto de actualización pasado, ni lo que realmente sucede dentro del modelo.
Esto significa que la vista, IMO, tiene que hacer un poco de trabajo al crear el registro pasado, ya que se supone que los controladores son apátridas y la vista es más persistente. Los controladores se disparan y ''kick-in'' hacen su trabajo con un objeto pasado y no tienen un estado.
Los datos pasados son creados por algún tipo de convención genérica.
Déjame ir aún más lejos. Supongamos que tiene una vista, una tabla y un control cuya propiedad habilitada depende del elemento seleccionado en la cuadrícula. PODRÍA crear una vista que maneje ambos controles y esta lógica internamente, y ese sería probablemente el camino a seguir. en un ejemplo tan simplificado.
Pero cuanto más atómicas son sus vistas, más reutilizables se vuelven, de modo que crea una vista para cada control, sí, para todos. Ahora está viendo una situación en la que las vistas deben conocerse entre sí para registrarse para la notificación correcta ...
Aquí es donde interviene el controlador, ya que queremos incluir todas estas dependencias en él, el desechable a largo plazo. Entonces, el controlador maneja este tipo de esquema de notificación view-to-view.
Ahora sus puntos de vista son ignorantes, ya que pueden ser independientes, por lo tanto, reutilizables.
Puede codificar una vista sin tener que conocer el sistema, o la "lógica de negocios" como les gusta llamarlo. Puede codificar un modelo sin tener que saber demasiado acerca de sus objetivos (aunque sí ayuda a modificar el modelo para permitirle devolver los conjuntos de datos que tiene en mente) ... pero los controladores, son los últimos y debe tenerlos los dos anteriores se reafirmaron antes de que puedas unir las cosas.
Aquí hay otra cosa en qué pensar, tal como se supone que el Modelo se abstrae, y proporciona una interfaz genérica para la implementación subyacente de los datos que administra (el cliente no sabe si los datos provienen de un DB, un archivo). , una configuración de programa, etc.): la vista también debe abstraer el control que está utilizando.
Por lo tanto, en última instancia, esto significa que una vista no debe (advertencia a continuación) tener funciones / propiedades que se vean así:
public property BackgroundColor{get;set}
Ni
public function ScrollBy(x,y){}
Pero en lugar:
public SetProp(string name, object val){}
Y
public DoCmd(string name, object val){}
Esto es un poco artificial, y recuerda que dije al final ... y preguntas por qué es esta una buena idea.
Con la reutilización en mente, considere que algún día puede exportar cosas de WinForms a, digamos, Flex o simplemente quiere usar una biblioteca de control novedosa que no exponga las mismas capacidades.
Digo ''puerto'' aquí, pero ese no es realmente el objetivo, no nos preocupa portar esta aplicación en particular, pero tener los elementos de MVC subyacentes lo suficientemente genéricos como para llevarlos a un nuevo sabor, internamente, dejando una capacidad y una capacidad consistentes. -interfase externa independiente intacta.
Si no hiciste esto, cuando aparezca tu nuevo sabor, todas tus referencias difíciles para ver las propiedades en los controladores (potencialmente reutilizables / refactorizables / extensibles) tienen que ser eliminadas.
Esto no quiere decir que tales setters genéricos y cmds tengan que ser la interfaz para todas las capacidades de tus vistas, sino que deben manejar las propiedades de ''edge case'' así como los apoyos / cmds normales que puedes exponer en la forma tradicional de hard-link . Piense en ello como un controlador de "propiedades extendidas".
De esa forma, (ideado de nuevo), suponga que está construyendo sobre un marco donde sus botones ya no tienen la propiedad buttonIcon. Eso es genial porque tuvo la previsión de crear una interfaz de vista de botón donde buttonIcon es una propiedad extendida, y dentro de la vista su código condicional no opera ahora cuando recibe el conjunto / get.
En resumen, trato de decir que los objetivos de codificación de MVC deberían ser dar al Modelo y Ver las interfaces genéricas a sus componentes subyacentes, de modo que cuando está codificando un Controlador no tiene que pensar demasiado sobre quién está controlando. . Y aunque los Controladores están siendo (aparentemente injustamente) configurados para ser el cordero sacrificial en el largo plazo de reutilización, esto no significa que TODOS sus controladores están destinados a la muerte.
Es de esperar que sean pequeños, ya que gran parte de su "pensamiento" se ha eliminado en Modelos y Vistas semiinteligentes y otros controladores (por ejemplo: Controlador para ordenar una cuadrícula o Manipular una TreeView), por lo que siendo pequeños se pueden ver fácilmente. y calificado para su reutilización en su próximo proyecto, o clonado y modificado para que sea adecuado.
¿Alguien podría dar un ejemplo de por qué sería ventajoso usar MVC en lugar de un modelo simple y una vista solamente?
Nota: ya sea que se llame MVC o MVP (Modelo-Vista-Presentador), estoy hablando de aquel en el que la Vista recibe entrada, entonces el Controlador responderá al evento de entrada interpretando la entrada en alguna acción que debe realizar el Modelo. Cuando el modelo cambie, la Vista se actualizará respondiendo a los eventos del modelo.
¿Cuál es la desventaja de simplemente dejar que el Modelo responda a los eventos en la Vista y viceversa?
En MVC, si cambio el modelo de una manera que afecte al controlador, entonces tendré que hacer cambios en el controlador. En Model-View, si cambio el modelo, tendré que actualizar la vista.
Entonces, parece que estamos introduciendo complejidad al agregar la parte de "controlador".
Las ventajas de MVC / P (estoy hablando de Supervisar el Controlador aquí) sobre MV incluyen:
Puede manejar código complejo de enlace de datos en el controlador, si es necesario.
Puede probar esa compleja lógica de presentación sin un marco de prueba de UI.
También puede hacer que un diseñador gráfico defina sus vistas, y no vea su código, y no estropee su código cuando arreglan sus vistas.
En realidad, reduce la complejidad al separar la lógica del flujo de trabajo de la lógica del dominio. También hace que sea más fácil escribir pruebas unitarias y hace que su aplicación sea más fácil de mantener y ampliar.
Imagine si desea agregar un nuevo tipo de datos. Con el enfoque anterior, probablemente duplicaría una gran parte de la lógica del flujo de trabajo en la nueva clase, ya que es probable que esté estrechamente vinculada a la lógica del dominio.
La disciplina involucrada en la separación de la lógica de flujo de trabajo en el controlador hace que sea más probable que tenga menos dependencias entre el flujo de trabajo y la lógica de dominio. Agregar un nuevo tipo de datos sería más simple, usted crea el nuevo objeto de dominio y ve cuánto del controlador puede reutilizar, por ejemplo, heredado de una superclase de controlador.
También haría más fácil cambiar los marcos en el futuro: el modelo probablemente no cambiaría demasiado y sería más portátil.
Una vez dicho esto, es posible que desee examinar MVVM en función de lo que está utilizando como su capa de presentación: Beneficios de MVVM sobre MVC