MVC para aplicaciones de escritorio sin capa de datos

Question

La pregunta puede ser complicada (por su naturaleza o por mi forma de describirla), así que realmente lea esto antes de responder.

Tengo esta aplicación para escribir:
a) aplicación de escritorio;
b) sin capa de datos en el sentido de base de datos, archivos o cualquier otro repositorio (no es necesario guardar, almacenar o cargar datos);
c) la aplicación tendrá algunos algoritmos de cálculo implementados (Algoritmo Genético);
b) proporciona GUI que mostrará los controles para la aplicación y los resultados de los cálculos.

Estoy pensando en usar el patrón MVC pero tengo dudas sobre cómo usarlo. Dado que no tengo una capa de datos en el sentido de (por ejemplo) base de datos (los datos se generan durante la ejecución en función de la entrada del usuario) me preocupa la forma de utilizar MVC en esta implementación. Hasta ahora he llegado con dos enfoques:

1. GUI es la Vista. GeneticAlgorithm es el controlador. GeneticAlgorithmResults es el Modelo (como clase que solo almacena datos). Flujo básico:

   • La vista envía la entrada del usuario al controlador;
   • El controlador está procesando la entrada del usuario y genera datos;
   • El controlador envía datos generados al modelo;
   • El modelo notifica a la Vista sobre nuevos datos;
   • La vista extrae datos nuevos y actualiza la pantalla.

2. GUI es la Vista. App Engine es el controlador. GeneticAlgorithm nad GeneticAlgorithmResults es el modelo. Ahora tenemos:

   • La vista envía la entrada del usuario al controlador;
   • El controlador está procesando la entrada del usuario y envía señales de control al modelo.
   • El modelo actualiza su estado interno (genera datos nuevos);
   • El modelo notifica al controlador sobre nuevos datos;
   • El controlador extrae datos al modelo;
   • El controlador procesa datos;
   • El controlador empuja los datos procesados ​​a la Vista;
   • La vista actualiza la pantalla.

Primera aproximación parece ser más sencillo y más como MVC. El problema es que parte de la lógica debería estar en el Modelo: decida cuándo notificar al modelo, ya que no se mostrarán todas las actualizaciones de datos, o tal vez la visualización se actualizará con los conjuntos de datos no todos los pequeños cambios. Esas decisiones se basarán en la entrada del usuario. Además, es posible que se necesite un procesamiento adicional de los datos antes de la visualización real. Esto estaría en la Vista.

Por otro lado, el segundo enfoque parece ser más complicado y parece que se están transfiriendo muchos mensajes para lograr la tarea.Pero le da un control total de la lógica al controlador y separa las responsabilidades de la vista, el controlador y el modelo (que es el propósito principal de MVC).

¿Qué enfoque recomendaría? ¿O tal vez debería mezclarlos y usar la arquitectura de primer enfoque con flujo de comunicación desde el segundo enfoque? O algún diseño diferente?

Answer 1

Desde mi comprensión de MVC, la segunda versión se parece más al estricto paradigma de MVC. Sin embargo, uno de mis profesores muy inteligentes me dijo una vez que los patrones de diseño están ahí para dar un conjunto de pautas y no necesariamente deben seguirse para el T.

En mi opinión, una mezcla de ambos es una buena idea. Si algún tipo de lógica termina en el Modelo, no es el fin del mundo, solo significa que debe tener más cuidado en hacer un seguimiento de la separación de sus componentes. Si una pequeña modificación a MVC hace que su vida sea un 50% más fácil (menos sobrecarga de mensajes), entonces es probable que sea una buena idea.

Answer 2

Definitivamente iré con algo más cercano a la segunda implementación. Sí, parece que hay más mensajes que se transmiten de un lado a otro, pero si la aplicación crece y cambia, te alegrará que hayas creado la aplicación con clases pequeñas.

Considera: ¿Dónde está la lógica para manejar tareas mundanas como cambiar entre algoritmos, ejecutarlos y procesar los datos para verlos?

Los algoritmos genéticos funcionan con algún tipo de entrada o datos de partida, ¿no es así? Lo obtendrías de tu capa de acceso a datos. ¿No necesita datos de inicialización o condiciones de inicialización? ¿Qué tal guardar sus resultados para archivarlos y recuperarlos para revisarlos más tarde? Creo que debes hacer esto una vez que tu aplicación madure. Espere que al principio use la persistencia basada en archivos. Si te sientes con ganas, más tarde puedes actualizar a una base de datos. Si codifica contra una capa de persistencia de datos abstraída, no tendrá que cambiar la lógica comercial más adelante para admitir el cambio de un archivo a una base de datos.

Debe utilizar el patrón de estrategia para implementar sus algoritmos. Esto le permitirá cambiar la implementación de su solucionador del algoritmo genético a sus otros algoritmos sin tener que cambiar la lógica comercial para cada algoritmo.

La capa empresarial verá un ISolver que toma entradas, y usted llamará a mySolver.Solve(). Debería poder cambiar entre las diferentes versiones sin tener que cambiar la lógica de la capa de su empresa (Open Closed Principle). La única diferencia en la forma en que la lógica comercial debe interactuar con los algoritmos debe estar en el constructor, e incluso allí, debe considerar el uso de un patrón de fábrica.