Cómo aplicar el patrón MVC al desarrollo de la GUI

Question

Soy un desarrollador web primario pero tengo una muy buena comprensión de C++ y C#. Sin embargo, recientemente escribí una aplicación GUI y comencé a perderme en cómo manejar la relación entre mi controlador y la lógica de visualización. En PHP fue muy fácil, y pude escribir mi propio patrón MVC con los ojos cerrados, principalmente debido a que PHP es sin estado y usted regenera todo el formulario por solicitud. Pero en los lenguajes de programación de aplicaciones me pierdo muy rápido.

Mi pregunta es: ¿cómo separaría mi controlador de la vista? ¿Debería la vista anexarse ​​a los eventos del controlador, o debería la vista implementar una interfaz con la que el controlador interactúa?

Answer 1

Si fuera usted, expondría los eventos desde una interfaz de su vista. Esto le permitiría hacer que el controlador sea central para toda la interacción.

El controlador carga primero y crea una instancia de la vista, yo usaría la inyección de dependencia para que no cree una dependencia en la vista en sí, sino solo en la interfaz. El controlador accederá al modelo y cargará datos en la vista. El controlador se uniría a eventos definidos en la interfaz de visualización. El controlador gestionaría el guardado de datos en el modelo a través de un evento.

Si lo desea, también podría utilizar un corredor de eventos que anularía la necesidad de declarar una interfaz por vista. De esta forma, podría vincularse a eventos a través de atributos.

Esto le dejará con el controlador depende del modelo y la interfaz de visualización, la vista depende de los datos solamente y el modelo no tiene dependencias.

Algunos ejemplos del pensamiento de diseño anterior se pueden encontrar en CAB y en Smart Client Software Factory Link To Smart Client. Usan el patrón MVP pero también se pueden aplicar fácilmente al patrón MVC.

Answer 2

imaginar esto GUI:

La unidad Zergling se presenta al usuario como un icono extranjero. Puedes ver que está en su animación inactiva. Llamar a esto la Vista.

El jugador mueve la unidad haciendo clic en ella y en una ubicación de destino. Puedes sustituir al jugador por una IA si lo deseas. Llamar a esto el controlador.

El rango de HP y ataque de la unidad se calcula en cada cuadro de juego cuando la unidad está en combate. Puede cambiar estos datos para convertir Zergling en una unidad de rango. Llamar a esto el Modelo.

Tenga en cuenta esta analogía y amplíela para sus diseños de MVC.

Answer 3

Lo más importante que debe recordar, es que en su configuración de MVC, el controlador debe saber qué vista llamar, pero la vista no debe saber nada del controlador.

De modo que su vista debe proporcionar una forma generalizada para que los controladores interactúen con ella, de modo que pueda tener varios controladores diferentes que llamen a la misma vista (una salida gráfica estandarizada de algunos datos proporcionados como parámetro, por ejemplo).

Esto le da flexibilidad:

1. Si el cliente quiere PDF de salida de algo que sólo proporcionan HTML salida para, puede salirse con la escribir un nuevo PDF Ver a llamarse desde el controlador con los mismos parámetros que la Vista HTML.
2. Si su cliente desea una salida HTML similar de una fuente de datos diferente (por ejemplo), puede codificar un nuevo Controlador que proporcione un conjunto de datos diferente a la misma Vista HTML anterior, que proporciona el mismo informe HTML solo con otra datos.

Si mantiene su Vista separada de los Controladores específicos, y pone el conocimiento acerca de qué Ver para llamar desde su Controlador, ya está en buen camino.

Answer 4

Su controlador debe vincularse definitivamente a los eventos definidos en una interfaz que implemente la vista.

Cómo hacer esto puede ser la parte difícil. ¿Inyección de dependencia? Una vista de fábrica? ¿Tiene la vista instanciar el controlador que quiere? Realmente depende de cuán compleja será la aplicación.

Para algo realmente rápido y simple, comenzaría haciendo que cada vista construyera su controlador y luego mirara otras opciones si necesitara agrandarse. Personalmente, creo que un marco de inyección de dependencia completo es excesivo para media docena de formularios:]

Answer 5

La mayoría de los marcos de GUI (desde MFC a SWT a lo que sea) ya están basados ​​en MVC. De hecho, el patrón MVC fue creado por primera vez por Smalltalk-80 y luego fue utilizado por primera vez para el desarrollo de GUI.

Revise y mire los estándares y prácticas sugeridas para su kit de herramientas GUI de elección. A veces MVC no será un buen patrón para trabajar cuando se resuelva un problema determinado o cuando se trabaje con un conjunto de herramientas en particular.

Recuerde: MVC es un gran patrón, pero no es una solución única para todos, no intente forzar un problema en MVC cuando la programación basada en eventos o funcional haga su vida más fácil.