La Capa de Lógica de Negocio: Separación y Eficiencia en el Desarrollo de Software

La capa de lógica de negocio (BLL) es un componente esencial de la arquitectura de software que separa la lógica de negocio de otras capas, como la de presentación y la de acceso a datos. Su objetivo principal es proporcionar una interfaz clara y concisa entre la capa de presentación y la capa de acceso a los datos. Actúa como mediador entre las dos capas y garantiza que la capa de presentación no tenga acceso directo a la capa de acceso a los datos.

La capa de lógica de negocio existe porque una aplicación necesita algo más que únicamente captar y actualizar datos; existe también una lógica de negocio adicional independiente de la capa de presentación. Es aquella que toma decisiones sobre los elementos que se muestran en la pantalla y las interacciones que realiza el usuario.

La lógica de negocio es independiente de la tecnología utilizada para interactuar con la forma de persistencia de los datos. Al interactuar con el objeto Mediador de objetos de negocio, la capa de lógica de negocio pasa los SDO (Structured Data Objects) al mecanismo de persistencia sin vincularse con la tecnología de persistencia.

Componentes y Funcionalidades de la BLL

La implementación SOI de la capa de lógica de negocio se expone a servicios, que transforman los mensajes OAGIS (BOD - Business Object Document) a pares nombre-valor para su proceso. Esto facilita la integración con mandatos de HCL Commerce existentes o personalizados. Los patrones de proceso BOD para solicitudes OAGIS utilizan la capa de persistencia para aceptar objetos de datos estructurados (SDOs) y manejar la correlación entre estos objetos estructurados lógicos y su forma de persistencia.

Elementos Clave en la BLL:

• Entidades comerciales: Son los objetos que representan los datos en la aplicación.
• Lógica empresarial: Es el código que implementa las reglas y la lógica del negocio.
• Acceso a los datos: Este componente se encarga de interactuar con la base de datos u otras fuentes de datos.

El BLL está diseñado para ser independiente de la capa de presentación y de la capa de acceso a los datos. Esto significa que puede utilizarse en diferentes aplicaciones y con diferentes fuentes de datos.

Su misión principal es preparar el contexto necesario y coordinar las decisiones que toma la lógica de negocio. Por ejemplo, imagina que usamos una base de datos para persistir el estado de la aplicación. Las decisiones de lógica de aplicación suelen ser sencillas, y el camino que sigue el código ha de ser casi recto, sin bifurcaciones.

Arquitecturas con Capa de Lógica de Negocio

Una aplicación bien diseñada se crea en capas distintas, cada una de las cuales encapsula un rol determinado. La programación por capas es un enfoque de diseño de software en el cual el sistema se organiza en distintas capas o niveles, cada una con responsabilidades específicas. Esto facilita el desarrollo, las pruebas, el mantenimiento y la escalabilidad de las aplicaciones.

La comunicación es uno de los costes más importantes en el desarrollo de software y a menudo no se tiene en cuenta.

Arquitectura de Tres Capas

La arquitectura de tres capas es un patrón de diseño de software que divide las aplicaciones en tres niveles o capas lógicas distintas: presentación, lógica de negocio y acceso a datos. Este enfoque busca separar las responsabilidades dentro de una aplicación, facilitando así su mantenimiento, escalabilidad y gestión. Es una de las arquitecturas más comunes, especialmente en aplicaciones empresariales.

Al separar la interfaz de usuario de la lógica de negocio y del acceso a datos, los desarrolladores pueden trabajar de manera más independiente en cada capa, mejorando la eficiencia del desarrollo y la calidad del software.

La siguiente imagen es un ejemplo de una arquitectura base de este tipo:

Este esquema puede ser utilizado en muchos casos, pero si vemos que la aplicación o librería es más complicada o tiene unos requerimientos específicos podremos cambiarla como queramos.

Capas de la Arquitectura de Tres Capas:

• Capa de presentación: Es la capa más externa y se encarga de interactuar con los usuarios finales. Su responsabilidad principal es mostrar la información al usuario y recoger sus entradas (inputs). Esta capa puede estar compuesta por páginas web, aplicaciones de escritorio, aplicaciones móviles, etc. En Angular, esta capa está compuesta por componentes, directivas y templates.
• Capa de lógica de negocio: Esta capa actúa como un intermediario entre la capa de presentación y la capa de acceso a datos. Contiene la lógica de negocio del sistema, que incluye reglas, cálculos y algoritmos específicos del dominio de la aplicación. Su tarea es procesar las entradas recibidas de la capa de presentación, aplicar las reglas de negocio pertinentes y enviar los datos a la capa de acceso a datos o devolver el resultado al usuario a través de la capa de presentación. En Angular, esta capa suele estar implementada en servicios, y además añadimos los modelos.
• Capa de acceso a datos: Es la capa más interna y se encarga de interactuar con las fuentes de datos, como bases de datos, archivos, servicios web u otras fuentes de datos. Su responsabilidad es recuperar, almacenar y actualizar los datos necesarios para la aplicación. Esta capa abstrae la lógica de acceso a datos del resto de la aplicación, permitiendo cambiar fácilmente las fuentes de datos sin afectar a las otras capas. En Angular, esta capa también se implementa en servicios, especialmente aquellos que se comunican con APIs externas.

Arquitectura Hexagonal (Puertos y Adaptadores)

También conocida como Arquitectura de Puertos y Adaptadores, es un estilo arquitectónico de software introducido por Alistair Cockburn. Esta arquitectura busca crear aplicaciones más modulares, independientes y adaptables al cambio, estructurando el sistema de tal manera que la lógica de negocio (núcleo) esté aislada de las interacciones externas.

Visualmente, la arquitectura hexagonal se representa como un hexágono con el núcleo en el centro, rodeado de puertos y adaptadores.

Componentes de la Arquitectura Hexagonal:

• Núcleo: Es el centro de la aplicación y contiene toda la lógica de negocio y las reglas fundamentales del sistema. En esta parte se definen las reglas que dictan cómo deben procesarse los datos y qué operaciones pueden realizarse.
• Puertos: Son interfaces que definen cómo el núcleo de la aplicación interactúa con el exterior.
• Adaptadores: Implementan los puertos y permiten que el núcleo interactúe con el exterior. Cada adaptador se encarga de traducir y adaptar los datos o la comunicación entre el núcleo y un sistema externo específico.

Los puertos de entrada representan las acciones que el núcleo de la aplicación expone para que puedan ser ejecutadas. Los adaptadores primarios permiten que los usuarios, interfaces o sistemas externos inicien operaciones en el núcleo. Los adaptadores secundarios implementan los puertos de salida y gestionan la comunicación con sistemas externos, como bases de datos o APIs de terceros.

Estratificación en Capas

En la estratificación estricta, cada capa solo puede comunicarse con la capa que se encuentra inmediatamente debajo de ella. Es decir, no se permite el salto de capas. La estratificación flexible permite que una capa pueda comunicarse con cualquier otra capa inferior, sin importar si está inmediatamente debajo o no.

Implementación de la BLL en Aplicaciones Modernas

La capa de acceso a datos (DAL) separa limpiamente la lógica de acceso a datos de la lógica de presentación. Sin embargo, aunque DAL separa de manera limpia los detalles de acceso a los datos de la capa de presentación, no aplica ninguna regla de negocio que puedan ser aplicadas.

Por ejemplo, para una aplicación, es posible que se desee no permitir que los campos CategoryID o SupplierID de la tabla Products se modifiquen cuando el campo Discontinued está establecido en 1, o es posible que se desee aplicar reglas de antigüedad, prohibiendo situaciones en las que un empleado es administrado por alguien que se contrató después de ellos. En este tutorial veremos cómo centralizar estas reglas de negocio en una capa de lógica de negocios (BLL) que actúa como intermediario para el intercambio de datos entre la capa de presentación y la DAL.

En una aplicación real, el BLL debe implementarse como un proyecto de biblioteca de clases independiente. Para separar de forma más limpia las clases relacionadas con DAL y BLL, vamos a crear dos subcarpetas en la carpeta App_Code: DAL y BLL.

Modelos de Datos para la Capa de Lógica de Negocio

Los modelos de datos desempeñan un papel crucial en la capa de lógica de negocio. Estos modelos son representaciones estructuradas de los datos que maneja la aplicación y facilitan la manipulación, validación y transferencia de información entre las diferentes capas. Es decir, definen la estructura y las reglas de negocio asociadas a los datos.

Los modelos de datos se definen como clases TypeScript que representan las entidades de la aplicación. Estas clases incluyen propiedades que corresponden a los atributos de las entidades y pueden incluir métodos para manipular los datos.

Ventajas de los Modelos de Datos:

• Claridad y Mantenibilidad: Los modelos de datos proporcionan una representación clara y estructurada de las entidades de la aplicación, lo que facilita la comprensión y el mantenimiento del código.
• Validación Centralizada: Las reglas de negocio y la validación de datos se pueden centralizar en los modelos, evitando la duplicación de lógica en diferentes partes de la aplicación.
• Reutilización de Código: Los modelos de datos pueden ser reutilizados en diferentes servicios y componentes, promoviendo la consistencia y la reutilización del código.
• Facilita el Testeo: La separación de las reglas de negocio en los modelos de datos facilita la creación de pruebas unitarias, mejorando la calidad del software.

Generación Automática de Capa de Acceso a Datos

La automatización en el desarrollo de software es una práctica que busca mejorar la eficiencia y reducir errores humanos. En el contexto de aplicaciones Angular, la generación automática de la capa de acceso a datos puede ser lograda utilizando herramientas como ng-swagger-gen. Esta librería facilita la creación de servicios Angular para interactuar con una API REST, partiendo de la especificación Swagger (OpenAPI).

Swagger es una especificación ampliamente utilizada para describir APIs RESTful. Permite a los desarrolladores definir de manera estructurada los endpoints, métodos, parámetros y modelos de datos de una API. Un archivo Swagger es generalmente un documento JSON o YAML que describe todas las características de la API.

ng-swagger-gen es una librería que automatiza la generación de servicios Angular a partir de una especificación Swagger. Estos servicios se encargan de manejar las peticiones HTTP y las respuestas de la API, facilitando la integración de la capa de acceso a datos en aplicaciones Angular.

Beneficios de ng-swagger-gen:

• Automatización: Ahorra tiempo al generar automáticamente el código necesario para interactuar con la API.
• Consistencia: Garantiza que la implementación de los servicios Angular esté en línea con la especificación Swagger, reduciendo errores y desalineamientos.
• Mantenibilidad: Facilita la actualización del código generado cuando la API cambia, simplemente regenerando los servicios a partir de la nueva especificación Swagger.
• Eficiencia: Permite a los desarrolladores centrarse en la lógica de negocio y en la interfaz de usuario, dejando que la herramienta gestione la comunicación con la API.

Validación de Nivel de Campo y de Negocio

La validación de nivel de campo es una comprobación que se refiere a los valores de las propiedades de los objetos de negocio al insertar o actualizar. Estas reglas pueden expresarse y deben expresarse en el nivel de base de datos. Los tipos de datos de esas columnas capturan el límite de caracteres de las columnas ProductName y QuantityPerUnit en la tabla Products.

Además de aplicar estas reglas en la base de datos, también deben aplicarse en el nivel DataSet. De hecho, la longitud del campo y si un valor es obligatorio u opcional ya se capturan para el conjunto de DataColumns de cada DataTable.

Para proporcionar este tipo de validación de nivel de campo (ej. UnitPrice debe ser mayor o igual que cero), es necesario crear un controlador de eventos para el evento ColumnChanging de DataTable.

Las clases BLL deben contener comprobaciones para garantizar el cumplimiento de las reglas de negocios de la aplicación. Imagine que nuestras reglas de negocio dictan que un producto no se pudo marcar descontinuado si era el único producto de un proveedor determinado.

Al llamar al BLL desde el nivel de presentación, podemos decidir si controlamos las excepciones que podrían generarse o dejamos que se propaguen hasta ASP.NET, lo que provocará el evento HttpApplicationError. Para controlar una excepción al trabajar con BLL mediante programación, podemos usar un bloque try...catch.