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…