Implementando el patrón Unit of Work en .NET

Introducción

El patrón Unit of work(unidad de trabajo), además de un patrón en desarrollo de software es una estrategia que nos permite gestionar y garantizar que transacciones y coherencia de datos sean de un nivel superior. Este patrón se puede combinar con una arquitectura limpia(clean architecture), dando lugar una aplicación con mayor escalabilidad y mantenibilidad a nivel de aplicaciones.

En este artículo vamos a sumergirnos un poco y explicar con .NET Core y bajo el paraguas de la arquitectura limpia, como podemos llevar a cabo una empleabilidad útil de este patrón de trabajo.

Más allá de la mera implementación, reflexionaremos sobre las múltiples ventajas que se obtienen al implementar la Unidad de Trabajo con la Arquitectura Limpia. Una de las joyas de esta fusión es el desacoplamiento exquisito entre las distintas capas de nuestra aplicación, una característica que resulta ser un salvavidas en la evolución y el mantenimiento del código a lo largo del tiempo.

Comprendiendo el patrón Unit of Work

El principal objetivo del patrón es gestionar las operaciones con la base de datos de forma que dispongamos de un mejor control de las transacciones y encapsular las múltiples operaciones como una simple unidad de trabajo. De la siguiente manera dispondremos de las operaciones relacionadas con el tratado de la base de datos juntas, tratados su ejecución y manejando los errores de una manera compacta.

A continuación ilustraremos cómo se vería de una forma más visual, partiremos de una aplicación básica sin intermediarios a nivel de base de datos, esta forma comprenderemos como y donde entra nuestro patrón.

Aplicación sin repositorio

En este ejemplo, el sistema se divide en dos capas principales.

• Capa de Presentación (Controladores): Esta es la interfaz de usuario o capa de API donde se manejan las solicitudes del usuario.
• Capa de Lógica de Negocio (Servicios): Aquí es donde se definen las reglas y operaciones comerciales.
• Estas dos capas interactúan directamente entre sí.
• La Base de Datos se accede directamente desde la Capa de Lógica de Negocio. Es decir, no hay una capa intermedia que gestione el acceso a la base de datos.

Aplicación con repositorio

En este ejemplo, el sistema se divide en tres capas.

• Capa de Presentación (Controladores): Similar al patrón anterior, es la interfaz de usuario o capa de API.
• Capa de Lógica de Negocio (Servicios): Define las reglas y operaciones comerciales.
• Capa de Acceso a Datos (Repositorios): Esta capa actúa como intermediario entre la lógica de negocio y la base de datos, abstrayendo las operaciones directas en la base de datos.
• La Capa de Presentación interactúa con la Capa de Lógica de Negocio, que a su vez interactúa con la Capa de Acceso a Datos para realizar operaciones en la Base de Datos.

Con Repositorio y Unidad de Trabajo:

Este patrón es similar al “Con Repositorio”, pero introduce un concepto adicional, la Unidad de Trabajo.

• La Unidad de Trabajo administra transacciones y agrupa múltiples operaciones de repositorio en una sola unidad lógica.
• El Repositorio en este patrón opera dentro del contexto de la Unidad de Trabajo.
• La Capa de Lógica de Negocio interactúa con la Unidad de Trabajo, que administra uno o varios Repositorios que acceden a la Base de Datos.

Implementación en aplicación .NET

Integración del Patrón de Unidad de Trabajo en Arquitectura Limpia

Para adaptar el patrón de Unidad de Trabajo en una aplicación .NET Core en el marco de la Arquitectura Limpia, sigue las siguientes recomendaciones:

1. Establecimiento de Interfaces Clave

   – Diseña una interfaz denominada IUnitOfWork. Esta será responsable de establecer el acuerdo para la Unidad de Trabajo, incorporando funciones esenciales como Commit() y Rollback().

2. Desarrollo de la Unidad de Trabajo

   – Elabora una versión específica de la interfaz IUnitOfWork. Esta versión se encargará de definir los bordes transaccionales y de coordinar las acciones con la base de datos. Es esencial que esta implementación ofrezca métodos para iniciar una transacción, validar cambios y, si es necesario, revertir una transacción.

Sincronización con Repositorios

   – Adapta tus repositorios para que operen en conjunto con la Unidad de Trabajo. Asegúrate de que cada función del repositorio opere dentro de la transacción establecida por la Unidad de Trabajo, garantizando que las modificaciones hechas se validen o anulen de manera colectiva.

4. Integración en la Capa de Aplicación

   – En el nivel de aplicación, incorpora la interfaz de Unidad de Trabajo en los controladores de comandos o consultas que demanden operaciones transaccionales. En estos controladores, lleva a cabo las acciones requeridas utilizando los repositorios que operan bajo la Unidad de Trabajo.

5. Manejo de la Unidad de Trabajo

   – En situaciones donde un comando o consulta demande operaciones transaccionales, accede a la Unidad de Trabajo mediante inyección de dependencias. Inicia la transacción con la función correspondiente y ejecuta las acciones de base de datos con los repositorios bajo el control de la Unidad de Trabajo. Concluye utilizando Commit() para confirmar cambios o Rollback() para revertirlos.

Ejemplo práctico

Imaginemos una sencilla aplicación de comercio electrónico para ilustrar el uso del patrón Unidad de Trabajo.

Definición de la Interfaz de Unidad de Trabajo:

Aquí se define una interfaz llamada IUnitOfWork que tiene tres métodos principales:

• Commit(): Para guardar los cambios en la base de datos.
• Rollback(): Para deshacer cambios si es necesario.
• GetRepository<TEntity>(): Para obtener un repositorio asociado a una entidad específica.

Implementación de la Unidad de Trabajo:

Dentro de esta clase, se tiene una instancia del contexto de la base de datos (DbContext) y un diccionario que almacenará los repositorios creados. Se implementan los métodos definidos en la interfaz y se agrega un método adicional Dispose() para liberar recursos.

Esta es la clase Repository, que actúa como un intermediario entre la lógica de negocio y la base de datos. Se encarga de las operaciones CRUD (crear, leer, actualizar, eliminar) para una entidad específica.

Aquí se tiene un servicio llamado ProductService que utiliza la Unidad de Trabajo para realizar operaciones relacionadas con productos. Por ejemplo, el método CreateProduct realiza lógica de negocio y operaciones de repositorio usando _productRepository y luego confirma los cambios con _unitOfWork.Commit().

En resumen, el patrón Unidad de Trabajo permite agrupar operaciones en una única transacción, garantizando que todas las operaciones se completen con éxito o que ninguna se realice en caso de algún error. Esta estructura también promueve una separación de responsabilidades, haciendo que el código sea más mantener y sea mása legible.

Conclusión

La conclusión es que el patrón Unit of Work proporciona un mecanismo sólido para gestionar transacciones y garantizar la consistencia de los datos en aplicaciones de .NET Core. Siguiendo los pasos descritos en este artículo, puedes aprovechar los beneficios del patrón Unit of Work para construir aplicaciones escalables y mantenibles.

El ejemplo práctico, demostró cómo se puede integrar el patrón Unit of Work en una aplicación de comercio electrónico para manejar operaciones en la base de datos. Con el patrón Unit of Work, los desarrolladores pueden garantizar que las operaciones relacionadas se traten como una sola unidad lógica, promoviendo la integridad de los datos y la consistencia transaccional.