Programación en capas

Posiblemente lo que voy a comentar en este post sea de lo más básico que pueda ser tratado, pero en los últimos tiempos, tanto como profesor de la universidad, como desarrollador y como entrevistador, he visto como este concepto básico por un lado y complejo al momento llevarlo adelante está fuera de toda capacidad intelectual del que trata de ponerlo en marcha.

Primero, tengo que decir que a veces se cruzan los conceptos y algunos hablan de capas, otros de “N-Tiers”, otros de “Multi-Tiers”, y muchos otros más que he escuchado por ahí, pero todos, los que les dan diferentes nombres, o el nombre que escucharon y asociaron apuntan a lo mismo; separar interfaz, lógica y datos para que sean lo menos dependientes unos de otros y nuestro código no se haga un masacote imposible de mantener.

Y es aquí donde entran en juego las confusiones, posiblemente por la forma en como se lo enseña.

1) ¿Cuántas capas debe tener mi modelo de capas?

– La respuesta correcta es: Tantas como sean necesarias. No debemos confundir el concepto lógico de separación en interfaz, reglas de negocio y datos como una regla de hierro inquebrantable, donde si o si necesitamos cumplir con este elemento. Por otro lado, es importante entender que a mayor cantidad de capas, o componentes, o DLLs, o proyectos, o la unidad en la cuál estén aglutinadas cada una de las capas, más procesos computacionales se requieren, más memoria u otros artefactos que se podrían necesitar para la ejecución del proyecto que estemos desarrollando. Por lo que optar por este modelo siempre, es un error. Como todo, la mejor solución es la que mejor resuelva el problema, no la que mejor sepamos usar.

2) ¡Yo se programar en capas!

– Este punto lo coloco aquí porque suele ser usado como un caballito de batallas por algunos nóveles del desarrollo. El saber programar en capas no es un plus, por lo tanto, cuando estés en una entrevista de trabajo, no entornes los ojos como si denotaras genialidad y digas: – Además, se programar en capas. Salvo que el entrevistador sepa menos que tu, solo conseguirás un pase rápido hacia la salida.

3) ¿Dónde pongo mi código?

– Si se entiende el concepto de separación en capas, entenderemos que cada una de ellas tiene un lugar y una responsabilidad. Siendo esto así, una capa próxima a la base de datos no debe saber ABSOLUTAMENTE NADA (Resalto para que no queden dudas) de que diantres pasa en la interfaz de la aplicación, por lo que pasarle un control de usuario, una grilla, una caja de texto, o cualquier otra cosa simplemente es una bestialidad (Vuelvo a recalcar por si quedan dudas). De la misma forma, cualquier capa que no sabe nada del manejo visual de la aplicación NO DEBE, nunca, jamás (NO, tampoco esa posibilidad que se te cruza por la cabeza) inmiscuirse en la misma. Por lo tanto, no puedes mostrar cajas de mensajes emergentes, levantar formularios, redireccionar a otras páginas Web, cambiar el color de una fuente, o lo que sea que se te pueda ocurrir. ¡SIMPLEMENTE, NO!.

4) ¿Cómo avisar si algo malo pasa en las capas de abajo?

– La palabra clave es excepciones. Pero para esto prefiero hacer referencia a tres videos realizados por Lucas Ontivero que explica de maravillas el porqué y el cómo. Video 1, video 2 y video 3.

Hay muchas otras consideraciones a tener en cuenta, y por supuesto, mucho más profundas, pero estas me parecen las más aberrantes y que he tenido que ver y escuchar mucho.