Casualmente, estoy trabajando en un proyecto de WinForms que se basa en MVC. No llamaría a esto una respuesta perfecta, pero explicaré mi diseño general y espero que esto pueda ayudarlo a encontrar el suyo.
Según la lectura que hice antes de comenzar este proyecto, parece que no hay una forma "correcta" de implementar esto. Seguí principios de diseño simples de OOP y MVC y el resto fue prueba y error a medida que desarrollé un flujo de trabajo.
¿MVC es simplemente una arquitectura inapropiada para este caso de uso?
No ..? No hay suficiente contexto en su pregunta para proporcionar una respuesta directa a eso. ¿Por qué estás usando MVC en primer lugar? ¿Cuáles son los requisitos no funcionales de su proyecto? ¿Tu proyecto va a ser muy pesado? ¿Te importa más la seguridad y prefieres una arquitectura en capas? ¿Cuáles son los principales componentes de su proyecto? Quizás cada componente necesita un patrón de diseño diferente. Averigüe por qué quiere usar este patrón de diseño en primer lugar y puede responder a su propia pregunta;)
Mi razón para usar MVC: es un patrón de diseño bastante simple de entender en mi opinión y mi diseño se basa en gran medida en la interacción del usuario. La forma en que MVC permite que el desarrollador separe las preocupaciones también es suficiente para mi aplicación. Esto hace que mi código sea mucho más fácil de mantener y probar.
También supongo que estoy usando más un diseño híbrido. Por lo general, el concepto ideal presentado en la ingeniería de software en realidad no se desarrolla en la práctica. Puede modificar el diseño para adaptarlo a las necesidades de su proyecto. No es necesario quedar atrapado en lo que está bien o mal. Hay prácticas generales, pero las reglas siempre se pueden doblar o romper siempre que no te dispares en el pie.
Mi implementación comenzó con un diseño de alto nivel que me dio una idea de qué componentes necesitaré. Es mejor comenzar de esta manera y avanzar en la arquitectura. Aquí está el diagrama del paquete para el proyecto (creado en StarUML):
Observe que cada capa, excepto la capa de presentación, depende del sistema de mensajería. Este es un "lenguaje" común que las capas inferiores y los subsistemas de esas capas usan para comunicarse entre sí. En mi caso, fue una enumeración simple basada en operaciones que se pueden realizar. Lo que me lleva al siguiente punto ...
Piense en las operaciones o comandos como la base para su implementación. ¿Qué quieres que haga tu aplicación? Divídalo en las operaciones más fundamentales. Por ejemplo: CreateProject, WriteNotes, SaveProject, LoadProject, etc. La GUI (o las clases Form) tendrán algún evento (como presionar un botón). Cada operación tiene un método de controlador asociado. En este caso, algo como Salir es demasiado simple. La aplicación simplemente se puede cerrar desde la clase Form. ¿Pero supongamos que primero quisiera conservar algunos datos de la aplicación en un archivo? Llamaré al método "Guardar" desde la clase de controlador correspondiente dentro de mi método de presionar un botón.
A partir de ahí, el controlador llamará al conjunto correcto de operaciones desde las clases de Servicio. Las clases de servicio en mi aplicación actúan como una interfaz para la capa de dominio. Validarán la entrada recibida de la llamada al método del controlador (y, por lo tanto, de la GUI) y manipularán el modelo de datos.
Una vez que se completa la validación y la manipulación de objetos correspondiente, el método de servicio devolverá un código de mensaje al controlador. Por ejemplo, MessageCodes.SaveSuccess. Tanto el controlador como las clases de servicio se basaron en los objetos de dominio y / o el conjunto general de operaciones que se pueden agrupar.
Por ejemplo: FileMenuController(operaciones: NewProject, SaveProject, LoadProject) -> ProjectServices(CreateProject, PersistProjectToFile, LoadProjectFromFile). Dónde Projectsería una clase de dominio en su modelo de datos. Las clases de controlador y servicio en mi caso eran clases no instanciables con métodos estáticos.
Luego, el controlador reconoce que la operación se completó sin éxito. Ahora, el controlador tiene su propio sistema de mensajería que utiliza para interactuar con la capa de presentación, de ahí la doble dependencia entre las capas de Servicio y Presentación. En este caso, el controlador siempre devuelve una clase llamada ViewStateen el ViewModelspaquete a la GUI. Este estado contiene información como: "¿ es válido el estado en el que intentó poner la aplicación? ", " Un mensaje legible por humanos sobre la operación que intentó realizar y por qué tuvo éxito o no (mensajes de error) " y una ViewModelclase.
La ViewModelclase contiene datos relevantes de la capa de dominio que la GUI usará para actualizar la vista. Estos modelos de vista se parecen a las clases de dominio, pero en mi caso usé objetos muy delgados . Básicamente no tienen prácticamente ningún comportamiento, solo transmiten información sobre el estado de nivel inferior de la aplicación. En otras palabras, NUNCA voy a regalar mis clases de dominio a la capa de presentación. Esta es también la razón por la cual los paquetes Controllersy Servicesdividen la capa de servicio en dos partes. Los controladores nunca manejarán clases de dominio ni validarán su estado. Simplemente actúan como un límite que convierte los datos relevantes de la GUI en datos relevantes del dominio que los servicios pueden usar y viceversa. La inclusión de la lógica de servicio en el controlador conduciría a una gran carga controladores, que son más difíciles de mantener.
Espero que esto te dé un punto de partida.