Deformed MVC

Estaba echando un ojo a algún artículo que hay por ahí sobre el patrón MVC. No sé muy bien por qué lo miraba, pero bueno...

El caso es que me he encontrado una vez más con la misma deformación del patrón. Es una deformación tan habitual, que me surge alguna pregunta. ¿Debería ser otro patrón, deberíamos darle otro nombre? O quizá ¿deberíamos sustituir con esta deformación el patrón original?

La pregunta se podría plantear de otra forma: ¿Es el problema que resuelven el mismo? Porque la solución claramente es distinta. Entonces si el problema que resuelven es el mismo, lo que habría que hacer es ponerse de acuerdo en cuál es la solución óptima y que esa sea la que forme el patrón. Pero si el problema no es exactamente el mismo, entonces claramente es otro patrón y habría que darle otro nombre para distinguirlos (porque en el fondo los patrones son para que nos entendamos y si lo que hacemos es dar el mismo nombre a dos cosas distinta,s pues eso no ayuda mucho).

¿Qué opináis? ¿Os habéis planteado en algún momento cuál de las dos opciones deberíamos seguir? ¿Habéis al menos notado el problema del que hablo?

#1   

No sé a qué te refieres: cuál es la deformación, cuál es el que llamas "original", coloca la fuente al menos de dónde lo has sacado, un enlace externo, o a otro hilo, o algo, y podremos responder XDDD

Más o menos intuyo por dónde vas, pero supongo que a simple vista, cualquiera que lea el hilo tal cual no sabrá seguirlo. El original es el que puedes encontrar en artículos y en libros más o menos serios. El resto de las cosas que encuentres en Internet es como todo: te puedes esperar lo mejor y lo peor. Incluso gente que hace las cosas de buena fe y en ocasiones mete la pata, entre las cuales me incluyo... imagínate si luego otro coge como fuente a uno de estos tipos: el bulo se expande más y más.

Yo el patrón MVC que uso es el que me enseñaron en la escuela y es el que tomo como bueno. No sé si tú lo verías en tu carrera, no voy a empezar con la discusión trasnochada ya entre ingenieros informáticos y de otras titulaciones, pero este tipo de cosas deja patente el por qué de nuestra titulación.

Es necesario anotar, de todos modos, que existen dos patrones MVC: el pasivo y el activo, que utiliza al patrón Observador. Ahora mismo no os puedo indicar la fuente de mis apuntes de la carrera, pero sospecho que sean del libro de Craig Larman, "Applying UML and Patterns". En mis apuntes tenía recogidos varios diagramas de bloques y diagramas de secuencia, explicando el flujo de interacciones entre los distintos bloques. Con ello quedaría bastante claro, pero lamento no poder colgarlos aquí.

#2   

Buenas, no sé exactamente a qué te refieres. Pero bueno, yo he visto implementar MVC de varias formas. La implementación suele variar bastante si se trata de una aplicación web o una aplicación de escritorio. Pero creo que en general la idea se mantiene: separar la vista de la lógica de negocio y tener una parte separada que se encargue de "conectar" modelo y vista a través de las acciones del usuario.

#3   

La idea es bien clara: el Modelo contiene la lógica de los datos, la Vista la presentación de esos datos y el Control maneja las peticiones del usuario (u otra aplicación externa) sobre esos datos del Modelo.

De manera que toda modificación del Modelo se realiza, utilizando la Vista, siendo estas peticiones controladas por el Control (valga la redundancia). Posteriormente, el Control actualizará los cambios en la Vista. Un Modelo se puede representar de numerosas formas, es decir, puede tener numerosas Vistas. Pensar como ejemplo en unos datos en una hoja de cálculo que pueden ser representados mediante un gráfico de barras, un queso, etc.

Este sería el MVC pasivo, en el cual si nadie lo pide expresamente, la Vista no actualizará los cambios ocurridos en el Modelo, en caso de que estos cambios se dieran sin petición expresa por medio del Control. El MVC pasivo es el que utiliza la gran mayoría de las aplicaciones de uso común.

La introducción que hace el MVC activo es empotrar un patrón Observador que actualiza la Vista automáticamente cuando el Modelo cambia, aun sin una petición externa gestionada por el Control. Ahora mismo se me ocurre tomar como ejemplo de este caso un monitor de datos en tiempo real.

#4   

Lo he hecho con toda la intención, claro :)

Cuando me refiero al patrón original, me refiero al que está centrado sobre el Modelo. En él, la relación entre las partes está definida claramente. El flujo es así:

• El Controlador actúa sobre el Modelo
• El Modelo se refleja en la Vista

Es decir, el flujo es unidireccional entre el Controlador y el Modelo y entre el Modelo y la Vista.

En esta imagen se ve claramente.

Son detalles importantes (para diferenciarlo luego del otro) que no hay flujo entre el Controlador y la Vista y que todos los flujos son unidireccionales. El Controlador está claramente definido como un actuador que ejecuta alguna acción sobre el modelo. No es un "dispatcher" de acciones, ni es un gestor de flujos. La Vista sobre el Modelo, generalmente estará implementada como un Observador o con algún mecanismo similar.

Luego está el otro patrón... Podría decir que es el MVP (Model View Presenter) pero lo cierto es que existen múltiples variantes y no todas coinciden con MVP. Ese ya es uno de los problemas, que cada uno pinta su diagrama como quiere y hace las cosas ligéramente distinto a como lo hace el resto. (Ver nota)

La diferencias (en mi opinión) fundamentales, son:

• Que algunos de los flujos son bidireccionales.
• El Controlador pasa deja de ser un simple actuador y adquiere un papel más amplio, con responsabilidades de gestión del flujo, de distribución de acciones... De hecho el Controlador pasa a implementar una parte de la lógica, en forma de reglas normalmente.

En cierto modo, podríamos decir que hay una diferencia en el reparto de papeles. En el primer caso Modelo es el protagonista, Controlador no es más que un mecanismo de input y Vista de output. En el segundo caso quien manda es Controlador, Modelo y Vista se ven sometidos a lo que él decide.

(Nota) Esto podría considerarse en sí mismo como un argumento para decir que entonces no hay patrón realmente. No hay una solución aceptada y reconocida como "la buena", sino toda una serie de aproximaciones. Pero bueno, mejor dejar este detalle que si no la discusión terminaría por otros caminos muy diferentes.

Está claro que en determinados situaciones, por la limitación del entorno, no podemos implementar satisfactoriamente la Vista como un observador puro del Modelo. Y no sólo eso, sino que coincide que en esas situaciones es bueno también que exista en algún lado ese papel de gestor de flujos y de distribuidor de acciones.

Lo cual ya se puede ver como otra parte del patrón que cambia, ¿no? Quiero decir, si nos quedamos con la idea de partida que el patrón es la suma de un problema, unas condiciones y una solución, entonces esto es el cambio de otra de las partes, las condiciones.

Mmmm... parece que yo me inclino por la opción de darle otro nombre porque es un patrón distinto...

#5   

No he entendido muy bien la segunda parte de tu última respuesta... Quizá has encontrado un MVC pasivo y un MVC activo y de ahí vienen las disputas y las dudas, que es de lo más normal si no te lo explican conjuntamente. Y si a ambas cosas lo llaman MVC sin más, el lío ya es de aúpa. Para mí, realmente el protagonista es el Controlador, que es el cerebrito del asunto, el que conoce al Modelo y sabe cómo manipularlo. Pero eso siempre, en el MVC activo y en el MVC pasivo. El Modelo es tonto, hace lo que el Controlador le dice, y la Vista también es poco espabilada, únicamente refleja los datos del Modelo.

"No hay una solución aceptada y reconocida como "la buena", sino toda una serie de aproximaciones."

Esta es la característica fundamental de los patrones arquitectónicos. A diferencia de otros patrones, como los de diseño (y todos nos iremos a los patrones del GoF, Gamma y cía), los patrones arquitectónicos jamás te dirán cómo hay que implementar el patrón dado para tu problema de una forma concreta, porque no estás trabajando con clases (diseño) sino con elementos muchos más abstractos: ¿paquetes, subsistemas, entes de otro tipo?. Te darán una estructura y unas aproximaciones de cómo montar el asunto. Unas reglas del juego, pero no un modo de juego, digamos. Otros ejemplos: patrón capas, patrón broker, etc. El patrón capas, por ejemplo, no te indica cómo tiene que ser cada capa, o qué tiene que incluir, sino cómo debe ser la interacción entre las distintas capas.

#6   

El Modelo es tonto, hace lo que el Controlador le dice

"Originalmente" (IMMHO) el Modelo es autocontenido y es listo. El Modelo es exactamente lo que dice su nombre, la modelización del problema a resolver, el propio sistema. El Modelo necesita ser listo. No es sólo el "modelo de datos" que decías arriba, sino que es el modelo del comportamiento del sistema.

El Controlador sólo le manda la señal del usuario. "Hola. Soy el botón Aumentar Potencia. El usuario me ha pulsado.". El Modelo entonces reacciona, sabe que aumentar potencia significa... modificar determinada variable o grupo de variables o aplicar las reglas que haya que aplicar. Posiblemente aumentar potencia pueda significar que el flujo de combustible aumenta, se abre el quemador para que entre más aire, se cambia el tiempo de apertura de las válvulas... (O sabe que "subir categoría empleado" significa "aumentar mínimamente el sueldo, duplicar las horas, asignar nuevas tareas..." whatever xD) Eso es el Modelo, esa es su responsabilidad. Si el modelo no sabe lo que significa Aumentar Potencia está incompleto.

Si hacemos que el protagonista sea el Controlador, entonces lo que conseguimos es dividir la lógica de comportamiento, separarla del Modelo y hacer que este sea un ente prácticamente inanimado.

(Nota: No, no es que haya visto nada hoy y me haya entrado ninguna duda. Es sólo que a veces me da por pensar en voz alta... o pensar con los dedos en el teclado xD)

#7   

Jajaja, lo último me ha gustado.

Ok, es muy posible que tengas razón. Lo que pasa es que yo entiendo al Modelo como las típicas clases que surgen del problema en sí. Estas clases, lógicamente, no son tontas, como dije antes, solamente fue una exageración. Lo que ocurre es que las clases (mejor dicho: las instancias de las clases, mejor dicho: los objetos XDD) tienen solamente conciencia de sí mismas, entiendo yo, y por tanto operan sobre sus propios atributos y poco más.

Es decir: pongamos un programa de gestión de librerías. La vista puede mostrar una lista de libros, y el usuario desea eliminarlos todos. El controlador debería recibir tal petición, entiendo yo que la lista de libros estaría mantenida y controlada en el Controlador, y luego sería el propio Controlador quien le indica a cada libro de la lista que se elimine, invocando el método adecuado de cada objeto Libro, que sería parte del Modelo.

Entiendo que tal lista debería estar en el Controlador porque no es parte intrínseca del negocio (y del Modelo, por tanto): lo que en un momento dado es una lista depués puede ser un sólo ítem, un árbol, o cualquier otra cosa. Es una cuestión de distintos niveles de abstracción, así lo veo yo. El Controlador podría tener un nivel de abstracción algo superior que el Modelo, y por ello podría ser apto para manejar estructuras de datos complejas (TAD) del Modelo, que podrían ser transitorias y que por tanto no serían propias del negocio en sí, sino simplemente una forma de organizar los datos en memoria en un momento dado.

Lógicamente, como tú dices, no se puede dividir la funcionalidad entre Modelo y Controlador de cualquier manera porque no se respetaría el principio de encapsulación, que vamos a tomar como algo bueno y necesario XDD. Simplemente aplico el principio de abstracción.

Joder, no sé si se entiende algo o esto ya entra un poco en lo filosófico...

#8   

Mmm... interesante... Me voy a comer.

#9   

¿Que les parece este desarrollo?
MVCC o MVC² ("Model-View-Controller/Connector")

http://svn.modxcms.com/docs/display/revolution/Developer+Introduction

#10   

A mí personalmente me gusta pensar en términos de SoC (Separation of Concerns o ~Separación de Capas) por que lo de darles esos nombres a las capas, teniendo en cuenta que vienen del mundo GUI, que el número de capas puede variar y que esas tres siglas llevan una carga semántica que puede inducir a error... pues ya "no me gusta" usar MVC.

Antes, y estoy hablando de 1998-99, quedaba mucho más claro a que te referías cuando hablabas de MVC en web, hoy en día se ha sobreutilizado tanto que es como hablar de "un CMS".

Para mí lo importante es que haya capas diferentes que se comuniquen por canales controlados y a través de interfaces establecidas, para que las "interioridades" de cada capa no afecten a las otras. Lo de si el modelo incluye la lógica o es sólo el "modelo de datos" para mí, es lo de menos. El problema es que si no quieres que la lógica esté en el "controlador" y el "modelo" es el modelo de datos, entonces te quedas sin sitio donde ponerlo, pero es por constreñirte mentalmente a 3 elementos y con esos nombres.

Pero volviendo al tema original: Sí, el nombre se ha degradado bastante y hoy en día no es una técnica si no más bien una idea a la que la gente da un nombre conocido por convención, pero vamos, no creo que haya que tomarselo literalmente.

Un saludo,
D.