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 podemos romper ese círculo vicioso?

Debemos aplicar las buenas practicas como cuando empleamos el principio SoC (Separation of Concerns) o separación de las partes, como se explica en este otro artículo  que habla de MVC, pero desde la arquitectura de ASP representa un reto.

 

Capas

Al principio puede parecer forzado, podría parecerles que quiero cambiar la arquitectura de ASP para que se adapte al modelo MVC, sin embargo no es así; la idea es aplicar un patrón ya probado en una arquitectura que puede ser mejorada, si sabemos que ajustes realizar.

El objetivo es aplicar principios y patrones para que nuestra aplicación pueda soportar los cambios y la evolución a la que se enfrentara durante el proceso de desarrollo e implementación en producción.

 

Tradicional ASP vs Capas:

Una aplicación típica desarrollada usando ASP.NET contiene paginas, que contienen controles, de tras de esa pagina existen manejadores de eventos que se codifican en el Code behind, los controles o el Code Behind lleva a cabo el acceso a los datos, posiblemente si son exigentes con su trabajo, a lo mejor tengan bibliotecas para esto, sin embargo la relación entre la interface y el Code Behind, es muy difícil de romper.

Para poder lograrlo, lo primero será identificar las responsabilidades que se encuentran entre mezcladas en ese modelo:

Puntos

1. Web UI
2. Manejo de eventos
3. Servicios
4. Clases que representan entidades en algún almacén de datos.
5. Código de acceso a ese almacén de datos.

Donde va cada cosa?

En una aplicación de capas se asignan responsabilidades en niveles que van desde el usuario hasta los datos. El Code Behind no es una capa.

Se debe identificar que contendrá cada capa, cuales serán esas capas y cuáles son las reglas de su uso e implementación.

 

Patrón de Modelo de dominio (Punto 4)

La programación moderna empieza por el modelado de Clases, así que lo primero será definir esta responsabilidad. Este patrón fue presentado por Martin Fowler en 2003 y según su definición

“Es un objeto que contiene comportamiento y datos”.

En este modelo debemos incluir toda la lógica de negocios, tanto datos como funcionalidades relacionadas a esta. Contendrá nuestras clases, si alguna clase requiriera de algún tipo de lógica para determinar un dato, esta lógica debe estar en esta capa.

Como una forma de mantener las partes independientes, se recomienda el uso de interfaces de código, que deberán ser implementadas por las clases.

 

Capa de servicios (Punto 3)

Esta capa intermedia será nuestro punto de comunicación entre la aplicación y los datos; para sustentar esta capa en patrones les diré que en un extremo se encuentra el patrón Facade y en el otro extremo el patrón ViewModel.

Una Facade  (es una fachada) por ejemplo una interface que debe enviar y recibir datos, estos datos deben ser tipificados para conseguir la relación, pero al mismo tiempo la independencia con respecto a la capa superior.

En esta capa se reciben los datos en forma de ViewModels  que se traducen en términos del modelo, para mantener la independencia entre las capas; si se presentará un cambio a nivel de los datos solo afectaría hacia un lado de la relación.

 

Capa de presentación (Punto 2)

Continuando con la aplicación de patrones, en esta capa usaremos el patrón MVP con sus siglas en ingles, Model-View-Presenter; contendrá interfaces para que sean implementadas por las formas web, lo cual refuerza la independencia de las capas.

 

Capa a nivel del usuario (Punto 1)

El reto más grande con respecto a la arquitectura ASP, es lograr que el control de que reside en la interfaz de usuario se traslade hacia las capas inferiores, para evitar que esta sea la que se encargue de crear los objetos, para ser una receptora de los mismos.

Esta acción es muy compleja de codificar, por lo cual vamos a apoyarnos en una biblioteca gratuita que podemos descargar de aquí.

 

Comentario Final

Este articulo podría parecer muy abstracto (y hasta cierto punto lo es), sin embargo si han leído los artículos que previamente publique en este mismo blog, deben tener las bases para entender lo que vamos a hacer.

Si no es el caso y les resulta confuso, entonces deben leer los siguientes artículos, ya que en ellos voy a desarrollar un ejemplo; podemos decir que este artículo es la introducción y deben leerlo para poder entender el ejemplo.

Y no se olviden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.