En MVC, el modelo es ciego a su entorno, la vista puede ser también - el fraude de imitación (ciegamente) sus eventos para el 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 cambiaba el modelo de una manera que afecta el controlador ...
El modelo debe exponer los métodos CRUD simples, de tal manera que los que utilizan los métodos no tienen que saber nada sobre el objeto de actualización pasado, ni qué sucede realmente 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 aprobados se crean mediante 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, por lo que crea una vista para cada, sí, cada control. Ahora está viendo una situación donde las vistas deben conocerse para registrarse para la notificación correcta ...
Aquí es donde entra el controlador, ya que queremos adherirle todas estas dependencias, 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 que 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á usando.
Por lo tanto, en última instancia, esto significa un punto de vista no (salvedad abajo) debe tener funciones/propiedades que se ven así:
public property BackgroundColor{get;set}
Tampoco
public function ScrollBy(x,y){}
Pero en su lugar:
public SetProp(string name, object val){}
y
public DoCmd(string name, object val){}
Esto es un poco artificial, y recuerda que dije en última instancia ... y preguntas por qué es esta una buena idea?
Teniendo en cuenta la reutilización, considere que algún día puede exportar cosas de WinForms a, digamos, Flex o simplemente desea usar una biblioteca de control novedosa que no exponga las mismas capacidades.
Digo 'portuar' aquí, pero ese no es realmente el objetivo, no estamos interesados en portar ESTA aplicación en particular, pero teniendo los elementos MVC subyacentes lo suficientemente genéricos como para llevarlos a un nuevo sabor - internamente, dejando una interfaz externa consistente e independiente de la habilidad intacta.
Si no lo hizo, cuando aparezca su nuevo sabor, todas sus 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 sus capacidades de visualización, sino que deben manejar las propiedades de 'edge case' así como los apoyos/cmds normales que puede exponer en la tradicional forma de enlace duro. Piense en ello como un controlador de "propiedades extendidas".
De esta 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, intento 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 tenga que pensar demasiado en ello. a quién controlas 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.
Ellos son, con suerte, pequeños, ya que gran parte de su 'pensamiento' ha sido empujado a Modelos y Vistas semiinteligentes y otros controladores (por ejemplo: Controlador para Ordenar una Grilla o Manipular una Vista de Árbol) se puede ver y calificar fácilmente para su reutilización en su próximo proyecto, o clonarlo y ajustarlo para que sea adecuado.
Voy a dar un ejemplo simple de por qué no vi la ventaja. Supongamos que estamos hablando de un auto. Se hizo clic en el botón Accelerate de Car View, el controlador responde llamando a Model.Accelerate(), luego se cambia la velocidad del modelo y View responde al evento del modelo y la lectura de la velocidad de actualización en la pantalla. Ahora, en Model-View (MV) Cuando se hace clic en el botón, Ver llamadas Model.Accelerate() y sucede lo mismo sin controlador involucrado. En MVC si cambio Accelerate() a IncreaseSpeed () Tendré que actualizar el controlador para llamar este método. En el caso de MV, haré la misma actualización pero a la Vista. –
Continuando comentario anterior: Entonces, las ventajas solo se aplican en los siguientes casos: 1. Sus vistas no son específicas de su proyecto actual (lo cual es raro). 2. ¡No puedo pensar en ninguno! (tal vez la falta de experiencia). –
Tiene un ejemplo 1-a1 allí. La vista tiene que saber todo sobre el modelo de CADA MANERA que afecta al modelo. Eso es un conjunto de dependencias, todo en un solo lugar. Mientras que con el controlador, ese grupo se divide, un controlador por separado para cada evento, y si tiene que ocurrir algo más elegante con el modelo en el evento, la alteración ocurre en el controlador (es decir, el potencial de reutilización de los controladores aumenta al ser solo aplicable a un evento). A tu manera, cada mejora/adición disminuye la reutilización de las vistas. –