Qué no es una aplicación en 3 capas

Una entradita de otro blog (bueno, no sé si esto puede llamarse pirateo) sobre qué es y qué no es una aplicación en 3 capas. La mayoría ya lo entendemos, pero está bien refrescarlo.
Por cierto, si se os hace corto o no os interesa mucho, tirad del hilo de nHibernate, que lo comenta de pasadilla pero es otra forma de implementar la DAL.
Y por cierto, no 'quejarze' de que está en inglés, que conmigo lo vais a aprender a base de bien...

Alternativas en el diseño de la DAL

Como ya se ha comentado, la aplicación se va a estructurar en 3 capas, Acceso a datos, Negocio e Interfaz. A continuación vamos a profundizar más en las opciones de diseño para la capa de acceso a datos (DAL, Data Access Layer). Hay que conocer algunas palabrejas que salen mucho por ahí, como:

• ORM (Object Relational Mapping), para la persistencia de objetos sobre una base de datos relacional. Se define la correspondencia entre los atributos de los objetos y los campos de la base de datos, de forma que automáticamente se gestione la persistencia de esos objetos, o bien se genera automáticamente la DAL que se encarga de esto.
• Reflection: es un espacio de nombres de .NET que permite conocer cosas de las clases y de sus métodos y propiedades, la palabra apropiada es metadatos, por ejemplo se puede saber qué métodos tiene una determinada clase y qué parámetros tienen esos métodos.
• Atributos: en los nuevos lenguajes de .NET se añaden atributos a las clases, métodos, propiedades... para realizar una programación declarativa. Estos atributos además pueden contener parámetros, suministrando valores concretos que aportan más semántica o concretan un comportamiento deseado. Ejemplo: al marcar un método como WebMethod se publica a través de un servicio web. Usando reflexividad, podemos acceder a los atributos de las clases y de sus métodos, realizando el comportamiento que queramos según los valores de esos atributos.
  

Bastante introducción, vamos al grano. Para la implementación de la capa de acceso a datos, tenemos un objetivo que puede definirse con una única frase: dotar de persistencia a los objetos de negocio con el mínimo acoplamiento. Necesitamos clases que puedan cargar un objeto de negocio a partir de un registro de la base de datos, y en el otro sentido actualizar la base de datos con los cambios realizados sobre el objeto de negocio (actualizar un registro, crear uno nuevo o incluso eliminarlo). Además, también deben ofrecer la funcionalidad de realizar consultas complejas sobre la base de datos (por ejemplo, qué registros cumplen una determinada condición, o cuántos).
Aunque obviamente debe haber relación entre la DAL y la BL (Business Layer o capa de negocio), con el mínimo acoplamiento queremos decir que la dependencia debe ser la mínima posible, con lo que los cambios, si es posible, sólo deban realizarse en una de las capas.

Opciones:
DataSet tipados
La opción propuesta por .NET para el RAD (Rapid Application Development) puede tener su utilidad en ese contexto, pero no se adapta a la arquitectura de 3 capas, ya que consiste en utilizar como contenedor único de datos al DataSet, y accederlo directamente desde la capa de interfaz. Si intentamos construir unos robustos objetos de negocio entre dichas capas (Datos e Interfaz), nos encontramos con que podemos acceder a los campos tipados que nos ofrece el DataSet, pero que necesitamos mucho código para conseguirlo. No voy a hablar mucho más de esta alternativa mientras no le encuentre una aplicación que realmente favorezca el mantenimiento a largo plazo de la aplicación desarrollada.

DAL usando atributos
El enlace os llevará a una serie de 3 artículos muy interesantes sobre parametrización de la información necesaria en la DAL dentro de la BL, lo cual de principio ya suena mal. Esa información se incluye dentro de atributos en la clase (indicando cuál será su tabla en la BD, e incluso podríamos llegar a detallar cuál será su BD, qué tipo, no qué ruta) y en las propiedades de la clase (para cada property indicamos cuál será su campo, e incluso su tipo de datos si es necesario). La DAL sólo con recibir una instancia de esa clase, puede acceder a sus metadatos y realizar la carga del registro que le pidamos (por ejemplo, el Id 14) sobre ese objeto sin ningún tipo de especialización más: un mismo objeto puede cargar todos los distintos objetos de negocio de la aplicación, con la centralización positiva y reutilización que eso conlleva.
Pero sí hay algo que suena mal: los objetos de negocio, y la BL en su totalidad, se hacen dependientes de una base de datos, al menos de un diseño de tabla concreto, ya que lo llevan incluido en ellos. Pero esta falta de elegancia se compensa por la comodidad que supone centralizar toda la información sobre el objeto de negocio: la implementación de las propiedades, de las reglas de negocio, y como atributos de las propiedades en campo sobre el que se realizará su persistencia.

dOOdads
Bonito porque usa herencia de una capa a la otra,con lo que además se separa muy bien el código autogenerado del propio, así como la capa de datos (base) de la de negocio (hija en la herencia); pero no parece que sea elegante: la capa de negocio depende de la de datos, me gustaría conseguir más independencia aquí. Además, no permite añadir código manualmente a la capa de datos (por ejemplo, para consultas específicas), al menos yo no he visto cómo (obviamente no puede modificarse directamente esa clase ya que es autogenerada y en cualquier momento, por un cambio en la BD, podemos necesitar volver a generarla).

Seguiremos buscando alternativas, pero de momento, creo que se me ha notado, va ganando la segunda, utilizar atributos para declarar la persistencia del objeto, creo que tiene 2 ventajas que suenan muy bien: facilita el primer desarrollo (sólo se requiere el esfuerzo para crear una clase genérica que ofrezca la persistencia, y luego reutilizarla), y facilita el mantenimiento (al estar todo junto, es más difícil que se nos olvide propagar un cambio).

Bueno, ya está bien por hoy, tranquilos que las siguientes entradas serán más breves... espero.

Nuevo proyecto

Hoy comienza oficialmente el proyecto Sota, en Nibisoft, abreviatura de SOlo TAlleres, cuyo objetivo es el desarrollo de una aplicación para la gestión de pequeños talleres según las siguientes líneas principales de diseño:

• Uso muy sencillo y guiado.
• Interfaz muy visual y gráfico, con numerosos iconos grandes (tipo XP) e imágenes y colores identificativos de los estados.
  
• Funcionalidad básica solamente.
• Evitando en lo posible las configuraciones y parametrizaciones.
• Monopuesto (aunque en su diseño permitirá la utilización multipuesto).
• Desarrollo sobre plataforma .NET 2.0 (VS 2005), usando una arquitectura de 3 capas (acceso a datos DAL, negocio e interfaz), con una DAL genérica que rellena cualquier objeto según los atributos declarados en este, y una interfaz WinForms conectada con la capa de negocio enlazando los controles (DataBinding) a objetos de negocio.
  

Se está terminando de elaborar la funcionalidad prevista del proyecto, y está pendiente comenzar el diseño de la interfaz de usuario y el diseño de los objetos de negocio para poder comenzar la implementación, que será por cuenta de un becario de la Universidad de Málaga sobre la beta 2 (en principio) de Visual Studio 2005, y utilizando una base de datos SQL Express 2005.

Como boceto de planificación, se propone liberar una beta completamente funcional tras un periodo de 3 meses, y disponer de 1 mes y medio más para finalizar la aplicación. Otros 15 días de la beca se dedicarán a la actualización de la página web de Nibisoft para la inclusión de información comercial sobre esta nueva aplicación (que por cierto está aún por bautizar comercialmente).