Conceptos: "Separar el código de la capa de presentación"

Muchas veces me han hecho esta pregunta, y muchas veces la he leído en foros de discusión, lo cual escribir repetidamente la respuesta se me hace un poco cansador.

En los próximos artículos voy a ir documentando estos casos, así cuando me lo vuelvan a preguntar, los remito aquí ;-)

En la programación por capas siempre debemos separar nuestro sistema en más de una "capa", donde por un lado tendremos una capa con la responsabilidad de implementar la "lógica" de nuestro sistema, y separar en otras capas las demás responsabilidades: capa de persistencia, de presentación (también llamada "interfaz" o "gui"), etc.

Capa de Lógica

A la capa de lógica también se le puede conocer con distintos nombres ("lógica de negocios", "dominio del problema", etc) y no necesariamente es una, puede estar compuesta por varias con distintos niveles de complejidad dentro (es decir, una capa que internamente tiene varias capas). Aquí es donde verdaderamente resolvemos el problema concreto, separado de los demás detalles que conforman nuestro sistema (que serían las otras capas, o las otras responsabilidades).

"Bajo Acoplamiento" versus "Reacción en Cadena"

Conceptualmente, lo único que debemos hacer es tener "separada" las responsabilidades en fuentes distintos, o en conjuntos de fuentes distintos (dependiendo el tamaño de nuestro sistema). Es decir, un conjunto de fuentes solo trabajarán la parte de la "lógica" donde tendrán prohibido hacer algo de la "presentación", y viceversa. Cada uno tendrá un punto de contacto que podrán ser datos pasados por parámetros, un objeto parámetro, una capa de "fachada", etc.

Aplicar cualquier estrategia que nos evite que nuestros subsistemas (o capas) estén "altamente acoplados", evitando que cada uno conozca detalles internos del otro para que cuando uno cambie no sea afectado en cadena la integridad de nuestro sistema, situación que nos obligará a modificar muchos fuentes para solucionarlo.

Un ejemplo práctico

En la capa de lógica tengo los fuentes que crean un resumen de cuenta de un cliente; arma la información necesaria a partir de los datos que fueron solicitados oportunamente a la capa de persistencia, para luego de terminada la tarea, cederle la responsabilidad a la capa de presentación para que -a partir de los datos ya procesados- armar una pantalla con columnas y colores, ubicando los datos donde corresponden.

La lógica no debe desplegar nada en pantalla ni tener acceso directo a la base de datos.

Su punto de contacto con los datos debe ser una clase que representará a la capa correspondiente a la cual le pedimos los datos con la mínima cantidad de información posible. No tendría sentido tener nuestro sistema separado en capas y que la lógica envíe sentencias SQL, lo que significaría que nuestra capa conoce demasiados detalles internos de otra capa, rompiendo el encapsulamiento. De la misma forma, tendríamos otra clase que representará a la "capa de presentación" que se encargará de recibir los datos y que nuestra "lógica" se desentenderá posteriormente (ya no será su responsabilidad).

¿PHP lo soporta?

Se puede hacer perfectamente con PHP, pero el tema es más simple de lo que parece: no debemos tener todo entreverado en los mismos fuentes, debemos ser ordenados y metódicos, separar cada objeto según su responsabilidad, y colocarlos en "contenedores" distintos.

Una forma de hacerlo es a través de herramientas, como Smarty, que permite trabajar separadamente tu código (la lógica) del código html (la presentación), donde dispondremos de un lenguaje propio para resolver problemas de la interfaz, facilitando la separación de capas.

Otra forma de hacer es con las propias "herramientas" que nos debería proveer el lenguaje (como sucede con Java o .Net), que nos facilitaría enormemente la administración y uso de las capas, tema tratado oportunamente en otro artículo en este blog.

Artículo basado en una respuesta que di en Foros del Web

3 comentarios:

Anónimo dijo...

Muy bueno tu articulo para empezar, me gustaria aprender mas sobre programacion en capas.
avisame cualquien nueva publicacion sobre el tema
ka_oss@hotmail.com

enrique_place dijo...

Estimado Ka_oss:

Es imposible, es inviable, es inmanejable, es incoherente, que pueda mantener una lista de personas para enviarles un aviso cada vez que hago un cambio en el blog.

¿Conoces el Patron de Diseño "Observer"?

Bueno, se aplica justamente para estos casos, y como es un "patrón" lo que dice es que representa el mejor diseño existente para este problema recurrente ;-)

En resumen, suscríbete al blog a través de la sindicación (RSS), la rueda ya fue inventada ;-)

Newman dijo...

Hola estimado charrúa, te saludo desde la otra orilla.
Te cuento que llegué a tu blog buscando información sobre smarty.
Estoy armando un sitio de clasificados de autos con un amigo y necesitabamos implementar de forma rápida una plataforma que con poco trabajo nos permitiera salir al cable si se me permite la expresión.
Toda mi vida profesional me la pasé en empresas y más que nada aprendí tecnologías closed source, más que nada Microsoft y Oracle pero hace unos años ya que abandoné ese ecosistema y me mudé al mundo linux y al desarrollo open source de la mano de PHP y MySQL.
La cuestión es que este paquete que compramos está cerrado con ionCube y lo poco customizable es la capa de presentación, que está armada con Smarty.
Hasta el momento no había tomado contacto con este sistema de plantillas más que muy por encima pero ahora me veo obligado por la coyuntura.
Y ya que estoy acá quisiera preguntarte para que tipo de proyectos utilizarías smarty, pregunto porque estimo que para proyectos de poca envergadura no se justificaría, al menos yo con cero experiencia lo veo como intentar construir un modelo a escala con tecnología aeroespacial, esto es así o se le puede sacar jugo igualmente en proyectos chicos?
También me gustaría preguntarte sobre tu experiencia con frameworks de desarrollo, más precisamente estoy interesado en symfony.
Estoy pensando en utilizarlo para una segunda versión del website que te comenté al principio y quizás estaría bueno acoplarlo con smarty, hasta eventualmente podría aprovechar parte del código de lo que será el viejo sitio.
Me preocupa el tema de la performance de estos frameworks, no he tenido tiempo de investigarlo a fondo y me da la impresión de que la ejecución va rebotando de aquí para allá hasta que llega a destino. Sería bueno saber hacia donde está orientada cada solución para ver si es viable utilizar por ejemplo symfony en un sitio como el que planteo con potencialmente miles de visitas/hora.
Bueno, te voy a dejar descansar un poco la vista.
Voy a navegar un poco el blog a ver que encuentro de interesante.
Acepto cualquier sugerencia que pueda aportarme luz en esto del desarrollo con PHP, me interesan los estándares probados como por ejemplo librerías para interactuar con la base de datos, seguridad contra code injection y sql injection, metodologías de trabajo que permitan ahorrar tiempo, como encarar con eficacia un website con gestión de contenidos, librerías de uso corriente para tareas comunes, url rewriting y ese tipo de cosas.
Obviamente no espero la solución a todos mis problemas sino la punta del ovillo.
Saludos!

Entradas populares