Recientemente, he estado hablando mucho sobre MVC ( Model-View-Controller ) con varios programadores en varios niveles en empresas de software. Encontré muchos malentendidos y ahora quiero compartir mis pensamientos sobre este tema. MVC es algo muy abstracto, y esta es la razón principal del malentendido: el grado subestimado de abstracción. Se manifiesta de la siguiente manera: un programador, por regla general, trabaja dentro del marco de un paradigma (OOP es nuestro todo) y mira el mundo a través de él. Y cuando escucha, por ejemplo, "controlador" - representa una clase. Y esto es un particular: una clase, o no una clase, o una colección de objetos o procedimientos, no importa. También hay ocasiones en las que la comprensión se ve distorsionada por un marco MVC específico. Intentaré influir en esto.



¿Qué es MVC?

Entonces, MVC tiene que ver con la interfaz de usuario (UI). No necesariamente gráfico, el control por voz también está bien. No olvidemos que un programa puede no tener una interfaz de usuario, puede tener una interfaz de programación (API) o puede que no tenga nada y aún así sea útil.

Pero si tenemos un usuario, entonces debe haber una interfaz de usuario. ¿Qué es una interfaz? Este es el límite adyacente entre los dos sistemas. En nuestro caso: por un lado - el programa, por el otro - el usuario. Aquí están.


El programa es completamente abstracto, cualquier código de materia. Sabe cómo hacer algo útil y el usuario tiene necesidades que se pueden satisfacer con este programa. Luego hay piezas de lógica que "saben" cómo, utilizando este programa, hacer directamente lo que el usuario quiere. Las piezas no son materia, materia lógica en el programa. Están más relacionados con el usuario con sus necesidades específicas, y son combinaciones de llamadas y llamadas al programa.

Casos de uso

Como ejemplo, imagine una terminal para operar en una bolsa. El usuario del terminal coloca una aplicación en la que indica que quiere comprar 20 acciones de la empresa UNIMINUTO a un precio de 500 Dólares por acción. También indica que la aplicación es válida por cuatro horas, y de cuál de sus cuentas se debe debitar el dinero, en caso de una transacción exitosa.

Una cantidad tangible de atributos. Pasa un tiempo y se da cuenta de que no será posible comprar a ese precio y está listo para subir el precio a 1.550 rublos, dejando todos los demás valores. Luego selecciona esta aplicación, hace clic en el botón "cambiar", indica un nuevo precio, sí. Es cómodo.

Pero el orden no se puede cambiar en el intercambio, no existe tal concepto en el área temática. La aplicación solo se puede colocar y cancelar. Para darle al usuario la oportunidad de cambiar la aplicación en un clic, es necesario recordar los valores antiguos, cancelar la aplicación, dar a editar lo que ha memorizado y enviar una nueva aplicación. Esa combinación. Pero para el usuario parece una acción simple: cambiar el ticket. A esto se le llama caso de uso.

Complementemos nuestro diagrama con un lugar para casos de uso.


El usuario también debe tener la oportunidad de extraer estos casos de uso y obtener el resultado. Estos pueden ser botones y otros elementos gráficos de entrada y salida, gestos, reconocimiento de voz y síntesis. Cualquier opción para intercambio de datos y comandos. Voila:


El usuario utiliza uno de los casos de uso, que, a su vez, manipula el programa. El programa publica el resultado o los cambios en su estado.

Entonces, ¿Dónde está MVC de todos modos?

Todo lo que queda es dar nombres familiares a los componentes resultantes.






Cuando un modelo publica cambios, no le importa quién, no sabe nada sobre la Vista. En lugar de o junto con View, puede haber otro subsistema en el otro extremo.

Ahora algunos detalles.

Era una variante clásica de MVC: modelo activo. También sucede que el modelo no notifica cambios. Entonces el controlador asume esta responsabilidad. Sabe qué tipo de manipulaciones está realizando en el modelo y, obviamente, sabe qué cambios pueden producirse en el estado del modelo. Este es el modelo pasivo.

Y un momento. La división del código en sujeto y no sujeto es condicional y depende de cuán pedantes queramos modelar el área temática. A veces es una decisión racional incluir algún caso de uso en el modelo. Quizás esto reduzca la cantidad de código en general y lo simplifique.