La arquitectura de mis proyectos MVC.

Dentro del desarrollo de software existen diferentes niveles de abstracción, cuando empezamos a escribir código lo hacemos al más bajo nivel o sea al nivel de los requerimientos, de las descripciones detalladas que nos permiten codificar esa lógica para que después forme parte de algo mucho más grande.

El nivel más alto de abstracción de un sistema es aquel donde podemos ver toda la estructura, sus componentes y las relaciones que estas partes tienen entre si; si quieren podemos decir que el termino ARQUITECTURA DE SOFTWARE es una analogía que hace referencia a la construcción de edificios. Algunos prefieren decirle diseño del software…

 

Buenas prácticas del patrón MVC.

Desde Que empecé a escribir código para MVC pude notar la enorme preocupación de quienes lo crearon, en el sentido de ofrecer mecanismos para hacer las cosas bien, con seguridad, para tener el control desde el principio.

Al conjunto de lineamientos para hacer las cosas bien, suele denominársele BUENAS PRACTICAS, no son reglas, no son verificadas por el compilador, ni afectan que la aplicación se ejecute; sin embargo si no las ponemos en práctica, es muy probable que nuestra aplicación se encuentre en riesgo o resulte extremadamente complicado su mantenimiento y escalabilidad…

 

Por qué MVC?

Tal vez aun sigan cuestionandose por que motivo vale la pena aprender MVC, asi que voy a tratar de darles algunos buenos motivos que les respondan a estas dudas.

Aun tal vez la razón mas importante sea que ante lo que ocurrió en el mundo exterior en todas las plataformas web que surgieron, las aplicaciones ASP.NET tradicionales lucen anticuadas y limitadas.

MVC surgió como respuesta a todas las críticas que recibió la plataforma ASP.NET y para poder ofrecernos a los antiguos clientes, forma de participar en las nuevas corrientes.

 

Recapitulemos.

Versiones van y versiones vienen, sin embargo el framework de MVC se ha superado en cada entrega, aun que actualmente se encuentra en la versión 4; (y ya estos jugando con ella) debo confesarles que aun estoy trabajando con la versión 3.

Recientemente le impartí un curso a unos cliente, que han sido acérrimos seguidores del ASP y que como es natural se habían resistido a voltear la mirada. Por fin lo han hecho, este articulo es el tema de introducción que les presente el primer día…

Capas con Entidades relacionadas (2 de 3)

Esta es la segunda parte del artículo donde se ejemplifica como usar la arquitectura de capas con entidades relacionadas.

Ya hemos presentado en el articulo previo la capa del doman Model, aun que aun debe ser modificada para incluir todos los controles que se requerirán por los cambios que introduciremos; además en esta segunda parte vamos a terminar con las capas superiores de este modelo.

Ejemplo ASP.NET en capas (3 de 3)

Una vez que hemos armado las tuberías de comunicación a la base de datos, podemos movernos un poco más arriba, en esta ocasión vamos a crear una capa que controla la comunicación entre la interface de usuario y la capa de servicios.

Me refiero a la capa de Presentación…

Ejemplo ASP.NET en capas (2 de 3)

Hasta este momento ya hemos creado la capa del Modelo de Dominio, y estamos listos para empezar la codificación de la capa intermedia; esta capa también llamada de Servicios, es la encargada de crear el vínculo de comunicación entre la capa a nivel de usuario y la capa de datos.
Su responsabilidad incluye todo aquello que se requiera para trasladar los datos en ambos sentidos, incluso las conversiones entre una vista y otra…

Ejemplo ASP.NET en capas (1 de 3)

Para poder entender algo tan abstracto y nuevo, será necesario que llevemos a cabo la creación de un ejemplo donde podamos ver de qué manera los patrones afectaran la estructura de nuestro proyecto.

El ejemplo es simple, pero que nos permite ver como se crean las capas…

ASP.NET sobre capas

La solución que ofrece Microsoft al problema del código mezclado es el Code Behind. Una forma al parecer simple de separar el código HTML del código VB o C#, en un archivo aparte.

Este archivo aparte contiene código que responde a los eventos que se disparan en la interface, y al final termina siendo una forma disfrazada de SMART UI, debemos romper ese vicio….

Como determinar que patrón usar.

Conocerlos y haberlos usado en alguna ocasión o por ejemplos, no es suficiente para poder determinar cuál sería el patrón que mejor se adapta a nuestro problema, incluso podría no ser necesario usar alguno.

Según mi propia experiencia puedo darles algunas ideas…

Patrones de diseño de software.

He hablado mucho sobre el tema, en los últimos post, incluso los he ejemplificado, y al igual que con otros temas dentro de este Blog, cometí el error de creer que todo el mundo debe haber escuchado de ellos, o al menos saber lo que son y lo que no son.

Así que ahora voy a tratar de exponer lo que para mí son los patrones de diseño de software.

MVC o Web Forms

Desde que empecé a trabajar con MVC dentro de la plataforma de desarrollo de Microsoft, me he preguntado que va a pasar con las Web forms? En la web podemos encontrar muchos lugares donde la polémica se pone caliente, hay defensores y detractores…claro de las Web forms. Porque el MVC fue recibido con los brazos abiertos por la comunidad, sobre todo aquellos que viene de otras plataformas de desarrollo.
Oficialmente Microsoft dice que las Web Forms es una tecnología madura dentro de la plataforma de desarrollo. Esta declaración es natural ya que con un gran número de proyectos desarrollados en esta tecnología, no puede crear una sensación de pánico, tampoco creo que la vayan a retirar del mercado…al menos no en un corto tiempo.

Arquitectura de software y Arquitecto de software.

La palabra arquitectura se puso de moda en el medio informático hace relativamente poco tiempo, recuerdo que la leí por primera vez en algún sitio de Microsoft y me pareció algo extravagante, ya que en aquel entonces yo no sabía lo que significaría este término en mi vida profesional. Aun hoy en día cuando debo presentarme y se hace alusión a que en mi trabajo me desempeño como arquitecto de software, me siento algo incomodo. Tal vez porque el termino ha sido idealizado por quienes estamos inmersos en hacer aplicaciones en el plano profesional.

Buen código?

Para poder apreciar lo que nos ofrece ASP.NET MVC es necesario que hablemos un poco de las buenas prácticas de desarrollo, de los patrones y sobre todo del buen código.
Empecemos por el buen código.
Este tema crea polémica cada vez que lo he tratado con otros programadores, sin embargo mis 25 años en el medio me permiten decir bastante sobre el tema. Sobre todo porque empecé a desarrollar cuando el código se desarrollaba usando una técnica conocida actualmente como Spaghetti Code, déjenme decirles que este tipo de código era una pesadilla y darle mantenimiento era casi imposible para alguien que no conociera el código.

Por que Microsoft MVC?

Para quienes hemos programado usando la plataforma web de Microsoft ASP, sabemos que la experiencia es definitivamente compleja. Dar mantenimiento a las páginas es algo realmente ridículo.
Pero porque es tan complejo el ASP?
La razón es porque la plataforma ASP tuvo una idea equivocada desde el principio, puesto que pretendía llevar a la web a todos lo que ya sabíamos programar usando Visual Studio, con eventos y controles, etc. Esto no es normal, ya que las aplicaciones debían correr sobre HTTP, y este protocolo no fue pensado para que fuera usado de esa manera, por consiguiente, Microsoft se metió en un sinfín de problemas tratando que mantener la idea funcionando, aun hoy en día sigue afirmando que la plataforma está viva, ya que al tener a tantos clientes cautivos, no puede dejarlos de lado.

Arquitectura MVC

Que significa MVC?
Son siglas en ingles de Model View Controller, y por casualidad se pueden usar de igual manera en español, como Modelo Vista Controlador.
Qué es?
Es una arquitectura de software, que logra el tan anhelado sueño de todos los programadores, que es separar los datos, de la lógica, de la interfaz de usuario.  Si les interesa la historia podemos decir que fue descrito por primera vez en 1979 en los laboratorios de investigación de Xerox.