Modelar, Vistear, Controlar o el MVC con SharePoint

Microsoft esta preparándonos desde hace ya algún tiempo una sorpresa mas, como si no tuviéramos suficientes para este año: el “ASP.NET MVC FrameWork”.

El MVC es una metodología para crear aplicaciones que divide la implementación en “Modelos”, “Vistas” y “Controladores”. En varios sitios regados por internet se encuentra suficiente información al respecto, así que no me meto en contar una vez más de que va el asunto. Jorge Dieguez ha escrito algo en este mismo Blog que da más que suficiente información al respecto: “Apuntes sobre el ASP.NET MVC Framework” (http://geeks.ms/blogs/jdieguez/archive/2007/11/24/apuntes-sobre-el-asp-net-mvc-framework.aspx ). Allí encuentran los vínculos a los artículos originales de Scott Guthrie, la persona encargada de desarrollar todo el asunto dentro de Microsoft. Y en el sitio de Microsoft ASP.NET pueden descargar el preview de las extensiones, si desean experimentar con los bits un poco (http://asp.net/downloads/3.5-extensions/ ).

Aquí tengo que confesar algo muy penoso: después de seguir el desarrollo del MVC por algún tiempo, y hacer pruebitas por aquí y por allá para mirar cómo funciona, no le encuentro la maldita gracia… probablemente se trate de que mi ignorancia es tan grande como mi falta de conocimientos, pero sigo sin ver cuáles son los beneficios con respecto a la separación en capas que hacemos desde hace bastante tiempo. O tal vez es pura deformación profesional, pues desde hace muchos años que no desarrollo aplicaciones Web de una manera regular… sea por lo que sea, en un campo puramente conceptual, desde hace mucho tiempo estamos haciendo separación de lógica (control) y presentación (vista). El MVC introduce el concepto de “Modelo”, que según Scott Guthrie son los componentes responsables por mantener el estado, por ejemplo persistiéndolo en una Base de Datos (“Models in a MVC based application are the components of the application that are responsable for maintaining state. Often this state is persisted insida a database”), así que estamos hablando de una capa de datos y del código para conversar con ella.

Continuando con lo que Scott (nosotros, los íntimos, lo llamamos cariñosamente Scotty 8-), “uno de los beneficios de usar metodologías MVC es que asegura una separación clara entre modelo, vista y control en una aplicación, lo que facilita el testeo”… lo mismo se puede decir de una aplicación bien diseñada de tres capas… opinión personal, por supuesto… Otros beneficios es que “es altamente extensible, todo es diseñado para poder ser reemplazado/cambiado”… mientras no modifiquemos la interface de objetos existentes, y solamente agreguemos nuevos componentes, toda dentro de OO es perfectamente extensible y modificable…

Yendo un poco más a la implementación de MVC, una cosa si tengo que conceder: el manejo de markup dentro de código en línea es más fácil. Cuando se usan controles Web en una página, el código que genera DOT.NET, especialmente para los identificadores es infame… miren en el código fuente HMTL de cualquier pagina de SharePoint, y lo verán lleno de barbaridades por el estilo de “id=ctl00$PlaceHolderSearchArea$ctl01$S6AE27B38_InputKeywords», con códigos incluidos dinámicamente que son imposibles de descifrar. Si queremos referenciar el código desde el code-behind, no hay problema pues ASP.NET reconoce el nombre por sí mismo, pero en el momento en el que necesitemos hacer algo al lado del cliente con JavaScript, la vemos negra para encontrar el identificador. MVC permite hacer referencias mucho más claras (por lo que he visto). Pero es esto una justificación para crear todo un FrameWork?

De una u otra forma, si estamos hablando de separación de capas, el concepto de SilverLight me parece mucho mas razonable que MVC. Todos los pica-código tenemos problemas con diseño y diseñadores gráficos, que alguien se atreva a tirar la primera piedra si no es así. Cuantas discusiones/irritación/peleas no he tenido en mi vida con diseñadores gráficos porque un azul no es azul suficiente y porque todo hay que moverlo un pixel a la izquierda porque “no está en balance”. Si Microsoft nos quiere librar de este tipo de pesadillas, SilverLight nos entrega un paradigma perfecto de separación entre presentación y lógica: que alguien se dedique a hacer colores bonitos y no le moleste la vida a los que tienen que hacer que las cosas funcionen…

No sé porque estoy pensando que MVC será uno más de los inventos de Microsoft que vendrán y se volverán a ir… alguien se acuerda del DNA de hace 10 años? Vino y se volvió a ir… antes del DNA estábamos haciendo aplicaciones de tres capas, después de él seguimos haciéndolas… la cuestión no es del FrameWork sino del diseñador(a) y del(a) desarrollador(a): si ello(a)s no hacen un buen trabajo, no hay FrameWork que haga milagros… seguimos siendo artesanos…

Y cuál es la relación con SharePoint? Por el momento ninguna, y todo depende de que tan fuerte apueste Microsoft para meternos el MVC. Si Microsoft decide por una u otra razón que aplicaciones Web tienen que ser desarrolladas con el MVC, lo tendremos que usar… probablemente no para la próxima versión de SharePoint, pero si para la siguiente. Por el momento, la arquitectura de SharePoint es claramente de tres capas, con una separación más que perfectamente definida. Como prueba, vea lo fácil que es modificar la interface, sin tocar la lógica. O modificar la lógica, sin tocar la interface. Y hablando de extensibilidad, lo fácil que es agregarle funcionalidad sin tocar ni la lógica ni la interface. Y la capa de datos está perfectamente escondida y protegida, de tal forma que ni la lógica ni la interface necesitan saber nada de ella. Yo diría, SharePoint es MVC al extremo sin la necesidad de MVC.

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

6 comentarios sobre “Modelar, Vistear, Controlar o el MVC con SharePoint”

  1. Hola Gustavo, me parece muy interesante tu opinión aunque discrepo en cuanto a tu apreciación sobre la utilidad del framework MVC.
    En mi opinión el MVC si es una framework útil:-) Además creo que los desarrolladores que hayan tenido que desarrollar alguna aplicación compleja al final han implementado en patrón MVC.
    El modelo ASP.NET de paginas+clase de respaldo hace que el patrón MVC se aplique de forma fragmentada, la pagina aspx es la vista, el código de respaldo es el controlador(los eventos) y el modelo(el código c#). Esto es un paradigma cómodo pero no muy efectivo para las grandes aplicaciones. Me parece muy positivo que MS formalice en u n framework una posibilidad distinta en el desarrollo ASP.NET. Lo que no tengo muy claro es donde colocar en SharePoint el framework MVC.
    Un Saludo
    Jorge Dieguez

  2. Hola Gustavo, me parece muy interesante tu opinión aunque discrepo en cuanto a tu apreciación sobre la utilidad del framework MVC.
    En mi opinión el MVC si es una framework útil:-) Además creo que los desarrolladores que hayan tenido que desarrollar alguna aplicación compleja al final han implementado en patrón MVC.
    El modelo ASP.NET de paginas+clase de respaldo hace que el patrón MVC se aplique de forma fragmentada, la pagina aspx es la vista, el código de respaldo es el controlador(los eventos) y el modelo(el código c#). Esto es un paradigma cómodo pero no muy efectivo para las grandes aplicaciones. Me parece muy positivo que MS formalice en u n framework una posibilidad distinta en el desarrollo ASP.NET. Lo que no tengo muy claro es donde colocar en SharePoint el framework MVC.
    Un Saludo
    Jorge

  3. Hola Gustavo;

    El patron MVC no es «algo» nuevo que Microsoft haya inventado, es un patron que fue ideado en la decada de los 70’s y existen varios lenguajes de programacion/plataformas que lo utilizan como base de desarrollo, por ejemplo Smalltalk, Objetive-C y Ruby on Rails.

    Por lo tanto no creo que sea algo «de moda» que vaya a pasar rapidamente.

    Microsoft lo implemento un tanto por la presion de los denominados «alpha-geeks», que son gente con influencia en el mundo .NET, principalmente en sitios/blogs en ingles.

    De hecho en modelo MVC no es nuevo en ASP.NET, ya desde hace tiempo existe Castle Monorail.

    La ventaja principal del patron MVC en ASP.NET es que permite una clara y real separacion del modelo, el controlador y la vista, cosa que con ASP.NET no es tan facil o tan intuitivo hacerlo, ademas de que permite realizar pruebas de unidad y «mocking» con una sencilles importante, cosa que puede ser muy util para muchos programadores.

    Te dejo de referencia este link de un post que escribi hace tiempo al respecto: http://mario-chavez.blogspot.com/2007/12/el-nuevo-microsoft-aspnet-mvc.html

    Saludos

    Mario

  4. Gustavo, comparto tu opinión plenamente. Cada vez veo más patronitis. Soy un defensor de los patrones, hace mucho que imparto formación sobre ellos, pero creo que cada vez se abusa más.

    Los patrones son soluciones a problemas complejos que cada vez más la gente usa para abordar problemas sencillos complicandolos.

    No he visto el framework MVC de Asp.Net pero no se porque me da que va a venir a complicar el asunto más que ha simplificarlo.

    Sinceramente, creo que es una sobrereacción a la framworkitis que tienen en el mundo Java. 25 frameworks para lo que hacemos en .Net con cuatro líneas.

  5. Gracias a todos por los comentarios…
    Jorge: Como decía en mi texto, puede ser que no le veo la gracia al asunto más por mi falta de conocimientos, que por qué no la tenga. O porque después de tantos años de trabajar «en tres capas» ya se ha convertido en una segunda naturaleza, de tal forma que si hay que mover una escalera, yo ya estoy pensando quien va a hacer la capa de datos (tomar las fotos), quien la interface (pintarla de rojo para que se vea bonita) y quien la lógica (conseguir el permiso del ayuntamiento), de tal forma que al final la escalera no se mueve…
    Mario: Gracias por el complemento… ya vas viendo que mi falta de conocimientos es más grande de lo que yo pensaba…
    Rodrigo: Necesitamos un doctor para que nos trate la fremeworkitis aguda que sufrimos… o tu y yo nos estamos haciendo viejos… 😎
    Un saludo a todos…

  6. Gustavo,

    Aparte de lo que dice Mario, además ASP.NET MVC en concreto Tira abajo toda la porqueria de VIEWSTATE y POSTBACK.

    Además como dice Mario, no es algo nuevo. Muchos lo venimos utlizando con MonoRail e incluso en otros lenguajes desde hace mucho tiempo. Pero para apreciar MVC hay que entenderlo bien y haber sufrido cambios y modificaciones en aplicaciones grandes.

    No se trata de hacerse viejo. Al contrario, los viejos son los que más experiencia tienen con este tipo de arquitectura (que no es realmente un patrón).

Responder a jdieguez Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *