Algo que comúnmente escucho en el círculo de desarrolladores (especialmente de .Net) es la frase “esto va en la capa de datos” o un “esta regla de negocio esta en la capa de negocio” y hasta un “mira, esta hecho pero aún no están bien separadas las capas”.
Esta palabrita, “capas”, es una de esas buzzwords de arquitectura microsoftica que nos han quedado grabadas en el cerebro, y que debido a que ha sido usada por tanto tiempo, ya la decimos instintivamente y hasta llegamos a creer que si un developer no habla en “capas” no es de respetar.
Comencemos a analizar lo que nos venden cuando hablamos de “capas”. Por lo general la terminología de capas se aplica a la típica arquitectura jerárquica de tres niveles, denotando responsabilidades diferentes y niveles de acceso variables en cada una de ellas, siendo la más conocida de todas la arquitectura de “tres capas”: Data Layer, Business Layer, Presentation Layer.
Personalmente creo que este tipo de “ensamblaje” cobra bastante sentido si desarrollabas hace más de 5 años atrás, es decir, los ORM eran “escasamente” conocidos, los DataSet’s reinaban en el mundo de Ado.Net, los webservices no eran más que una extensión de la ASP.NET framework, el desarrollo en Windows y Web se limitaba en su gran extensión a arrastrar y soltar controles sobre un lienzo y crear un test era cosa de escribir en un papel y decirle a alguien que “probara la aplicación”… ¡ahhh, épocas lejanas aquellas! (bueno, creo que mucho de lo que menciono aquí aún esta presente en la lucha hasta el sol de hoy, pero ese es otro tema).
Actualmente muchos siguen desarrollando de esa manera, algunos han llevado esto aún más lejos y se han atrevido a hablar de arquitecturas de dos capas y hasta de n-capas… Hay libros, guías (como esta) y muchísimos posts en internet conversando de como usar Nhibernate o la Entity Framework en un entorno de n capas, como concurso, mientras más capas tenga tu aplicación, mayor será tu “mérito”.
He llegado a entender a aquellos defensores de las arquitecturas por capas, y en base a ello he formulado un conjunto de opciones por las cuales aún hablamos acerca de “capas”
- Han tanta lógica en la base de datos que hay que distinguir las reglas embebidas en la base de datos de aquellas embebidas en cualquier otro lugar, por lo tanto, hablamos de las reglas de la “capa de datos”
- La base de datos es mi salvador, por lo tanto debo separarla y distinguirla del resto de código “mortal” de la aplicación
- La presentación de los datos es tan compleja, que bueno, el codebehind es inmenso y merece tener su propia “capa” debido al tamaño
- Sigo usando DataSets o procedimientos almacenados que son leídos por DataReaders y al final debo manipularlos para sacar los datos de una factura, consumidor o lo que sea, por lo tanto tengo que distinguir esas responsabilidades en su propia “capsula”
- No sé que rayos es un Tier y a falta de mejor palabra le llamo Layer
Como sea, pronto conversaremos de porqué el concepto de “capa” está un poco pasado de moda y las opciones que tenemos a la mano para reemplazar la ya vieja arquitectura por capas por una mucho más holística basada en modelos de comportamiento y responsabilidades modeladas a base del dominio y no por imaginación de un arquitecto.
Como siempre, estoy abierto a comentarios en la zona de comentarios, twitter, mail o cualquier otro medio por el cual esporádicamente puedan encontrarme.
¡Hasta la próxima!
Pingback: El espejismo de la separacion por capas, toma dos | IDisposable Thoughts