¿Cuánta lógica de GUI es demasiado en MVC?

Question

Estoy escribiendo una pequeña aplicación de escritorio Java y estoy usando un patrón MVC. He leído sobre cómo debe mantenerse la lógica en el modelo, pero hay algunos lugares en los que se debe aplicar la lógica, pero está completamente relacionado con el funcionamiento de la GUI. También he leído que las capas deben diseñarse para permitir una vista "conectable", lo que significa que si desea convertir la aplicación en una aplicación de línea de comandos, aún así debería poder utilizar el mismo modelo con un mínimo problema.

En mi aplicación, se muestra una imagen en un panel de un panel dividido. También hay una casilla de verificación que determina si la imagen cambia de tamaño de forma dinámica a medida que el usuario cambia el tamaño del panel. Siento como si tuviera dos soluciones posibles:

1. Cuando el usuario hace clic en la casilla de verificación, el valor se almacenaría en el modelo . Cada vez que se cambia el tamaño del panel, ese valor se verificará para ver si la imagen debe ser escalada.

2. Dado que la casilla de verificación sólo se refiere a cómo funciona la interfaz gráfica de usuario, no se molestarían almacenar el valor en el modelo, y me gustaría comprobar la casilla directamente al redimensionar el panel.

Esto es un ejemplo atenuado, pero ilustra mi problema. ¿Estoy tomando la separación de la lógica demasiado extrema aquí?

Answer 1

"lógica" se puede dividir en tres categorías para MVC:

• lógica de validación - esto debe estar en el modelo.
• lógica empresarial/de repositorio: debería estar en el controlador.
• Lógica de visualización y comportamiento: esto debería estar en la vista.

Suena como, en su ejemplo, que está en lógica de comportamiento (es decir, la vista) en este momento.

Answer 2

No toda la lógica debe estar separada de la vista, pero la lógica de negocio definitivamente debería ser.

También extraería la lógica relacionada con la interfaz de usuario en clases separadas, pero para el Separation of Concerns.

Una regla efectiva para la separación de preocupaciones es hacerse la siguiente pregunta: "Si cambia un requisito (relativo a UI, validación, etc.) - ¿qué partes/clases de mi aplicación tendría que cambiar?"

Answer 3

Eche un vistazo a Presentation Model.

Presentación Modelo:

Represente el estado y el comportamiento de la presentación independientemente los controles GUI utilizados en la interfaz

que he encontrado este problema muchas veces. Imagina que te piden que hagas lo siguiente.

El control B debe aparecer si el día es lunes.

Bueno, eso es lógica de negocios y no debería estar en la Vista. La vista no debería preocuparse por este tipo de lógica. Lo que la vista solo necesita saber es si se debe mostrar un cierto control o no. Por lo tanto, para cumplir esto, podría tener una clase que tenga todas las propiedades apropiadas necesarias para la vista más una propiedad llamada isBvisible. Esa propiedad isBvisible podría haberse llenado desde una capa de servicio y devuelve el objeto necesario para la visualización de los datos.

Answer 4

El primero es verdadero MVC. El segundo no es MVC es particularmente importante para, como dijo kostja, la separación de preocupaciones. En proyectos más grandes, esto puede ser crucial para hacer un seguimiento de qué está pasando en dónde. En proyectos más pequeños (que son únicos, o no se usarán en una configuración de producción, o son herramientas internas, o lo que sea), es un problema menor.