post sobre MVC

[SidP]

hola foreros..recientemente encontre este tema en la lista symfony...donde daban el link a un post sobre MVC
http://mundogris.wordpress.com/2008/...a-para-la-web/
muchos han sido los post sobre este tema por estos lares...pero ustedes que creen de este?

Salu2

[venkman]

En buena parte tiene razón. Pero sólo en parte. Además, en algunos de los detalles se pierde bastante.

Lo aclaro:

1. Arquitectura vs. patrón
Como ya dije en otro mensaje, MVC no es una arquitectura. Es un patrón de diseño. En su origen se aplicaba como patrón de diseño, para solucionar un problema concreto, no para establecer la arquitectura completa de una aplicación como dice.


2. MVC: Qué soluciona.
MVC es un patrón, como más o menos explica el comentario, que soluciona la separación entre 3 preocupaciones existentes en el problema de hacer que un usuario interaccione con algún objeto de la aplicación. Las 3 partes son:
- Por un lado está el concepto, el objeto que queremos manipular. En una aplicación que gestiona una cocina automatizada, por poner un ejemplo, esto sería la propia cocina, con sus características, sus funcionalidades y aparatos.
- Por otro lado está la visualización del estado de la cocina. A qué temperatura está el horno, qué presión hay en las ollas, qué calor está produciendo el fuego, cuánta agua hay en... Todo eso necesita monitorizarse, visualizarse de algún modo.
- Por último el cocinero, debe poder manejar la cocina. Así que habrá un dial para aumentar o disminuir la potencia del horno, otro para establecer la temperatura del termostato, un mecanismo que tape o destape las ollas, que ...

Así que separamos nuestro problema en 3 partes:
- El modelo representa la cocina en sí.
- Las vistas serán los diversos indicadores que tengamos para ver el estado del modelo.
- Los controladores serán los diversos mecanismos, actuadores, etc, que tengamos para actuar sobre el modelo.

Es muy importante notar que este es el único aspecto que soluciona el patrón MVC. En la cocina existirán otros muchos aspectos a tener en cuenta. ¿El modelo necesita acceder a los alimentos para cocinarlos? Claro, pero ese es otro problema. ¿Debemos impedir que alguien no autorizado pueda manejar los controles? Por supuesto, sólo el cocinero debe poder... pero de nuevo es otro problema distinto. MVC no se ocupa de esos aspectos de la aplicación.


3. Patrón
Ahora hay que parar un momento y pensar qué es eso de un patrón. Ya arriba decía algo, que no es una arquitectura. Bien, pero ¿qué es?
Un patrón es la suma de estas cosas:
Una situación (1) conocida en la que tenemos un problema (2) que solucionar, y una forma de solucionarlo (3) que sabemos que es apropiada para ese problema en esa situación.

La situación abarca todo el entorno de definición de nuestro problema, que a su vez es la preocupación que queremos poder manejar. La solución debe ser, por encima de otros aspectos, una que sabemos que es apropiada para ese problema en esa situación. Y ojo, porque es importante la parte de "en esa situación".


4. Problemas con el entorno web
El problema principal de aplicar la solución que propone MVC al entorno web, es que ya no es la misma situación que la definida en el patrón. Hay algunas diferencias importantes.
La más importante de todas es que la vista no puede ser activa (salvo haciendo mucho mucho esfuerzo). Esto es una pega porque para realmente poder separar las tres partes M, V y C (que es lo que busca el patrón, la separación de responsabilidades) la vista debe poder recibir o percibir los cambios que se produzcan en el modelo. La vista debe ser como una grabación en video, algo que permanentemente extrae (o lo recibe) el estado del modelo.

En web -y quitando como decía antes hacer muchas "trampas"- esto no es posible. La vista no puede monitorizar el modelo. La vista sólo se actualiza cuando lo decide el usuario (cuando hacemos click en algo).


5. Variaciones sobre un mismo tema
Sin embargo, el objetivo de separar las responsabilidades sigue siendo un objetivo interesante. Por eso mismo se han buscado ciertas variaciones sobre el patrón MVC. Lo que ha ocurrido, tras diversas iteraciones, es que lo que ahora mucha gente llama MVC ya no es lo mismo que lo que se llamaba MVC originalmente. En buena medida a esto ha contribuido Sun con un documento en el que no supo elegir mejores nombres que "Model 1" y "Model 2". "Model 2" es lo que básicamente se conoce como MVC cuando hablamos de entornos web.


6. Problemas con las personas
Las personas, todos vosotros habitantes de este planeta (xD), tienden a dar nombres a las cosas para ganar ventaja sobre ellas. Se da nombre a lo que se desconoce para hacerlo más conocido y familiar, se da nombre a lo que no se sabe cómo llamar para poder así comunicarlo a otras personas. Con MVC ha ocurrido esto de una manera muy notable. "Model 2" es un nombre estúpido. más aún cuando "Model 1" es uno que nunca nadie va a querer usar intencionadamente salvo para decir "No lo hagas según el Model 1". Así que alguien empezó a asociarlo con el MVC. Porque sí, tiene cierto parecido. Así se ha terminado llamando MVC a varias cosas distintas.


7. Sobre la validez de la conclusión
Efectivamente MVC, el original MVC, no es apropiado para aplicarlo en web. Pero sin embargo hay una serie de detalles que el artículo equivoca.

• No hablamos del MVC-original, sino del MVC-Model 2. Como tal, tendrá sus ventajas e inconvenientes, pero claramente sí es aplicable en el entorno web.
• No hablamos de una arquitectura, sino de un patrón. Las aplicaciones web tendrán una arquitectura determinada y, para algunos de sus problemas, podrán o no, aplicar unas soluciones u otras. Usar un Singleton, una AbstractFactory o una Estrategia, no hace que tu arquitectura sea Singleton, AbstractFactory o Estrategia. (*)
• MVC no se preocupa en absoluto por la persistencia del modelo. Esto es algo completamente independiente y ajeno al patrón MVC.
• MVC no es exclusivamente para entornos de bitmaps. En absoluto. Ha sido perfectamente aplicado en otros ámbitos.
• Todo esto está muy bien si lo miramos desde un punto de vista rígido, pero las normas están para 1. conocerlas 2. respetarlas y 3. saber cuándo romperlas y con qué consecuencias. Si nos quedamos únicamente en los puntos 1 y 2, nunca se produce el progreso. El avance, el progreso del conocimiento, la técnica, la tecnología, la ciencia, sólo ocurre cuando conociendo las reglas establecidas sabemos cómo romperlas, por qué romperlas y qué consecuencias tiene hacerlo. El progreso se produce entonces cuando, conociendo esas consecuencias, las aceptamos las desventajas a cambio de las ventajas que nos pueda aportar.

En fin, lo más importante de todo esto es ese último párrafo en plan filosófico (xD) y el primer punto de todos: No confundir patrón con arquitectura. La arquitectura define toda la organización y estructura de nuestra aplicación. Un patrón sólo define una estructura para un determinado aspecto de la aplicación o para solucionar un determinado problema.




(*) Se me ocurre una situación muy posible, que es la de implementar dentro de una misma página, con Javascript, una parte del modelo, o un modelo de presentación y que ahí apliquemos el patrón MVC. Es perfectamente aplicable en ese caso el MVC original.

[venkman]

Ah, por cierto... Perdón por el rollo que he soltado. Cuando me pongo, me cuesta parar... ¿Qué? ¿Que os habéis dormido? Bien, bien, dormir es bueno. Dulces sueños xD

[SidP]

no para nada que me he dormido...muy buen post venkman...muchisimas gracias por el aporte....a veces nos perdemos entre blogs y aparecen cosas que vale la pena aclarar...asi son las cosas en la web 2.0

Salu2

[GatorV]

Muy buen post venkman, creo con lo que pones aclaras muchos detalles que muchos usuarios dan por hecho cuando están usando un Framework, siempre es importante saber el que y como de porque funcionan de cierta forma las cosas.

Saludos.

[pablofmorales]

Iniciado por venkman

Ah, por cierto... Perdón por el rollo que he soltado. Cuando me pongo, me cuesta parar... ¿Qué? ¿Que os habéis dormido? Bien, bien, dormir es bueno. Dulces sueños xD

Bueno, espero que te pongas mas seguido si vamos a conseguir comentarios como estos.

Saludos, y una excelente explicacion