Patrón Unit of Work (UoW) o Unidad de Trabajo

Definición

Este patrón tiene como objetivo tratar como una Unidad todos aquellos objetos nuevos, modificados o eliminados con respecto de una fuente de datos.

Martin Fowler, ya realizó una descripción de UoW en su libro “Patterns of Enterprise Application Architecture”.

Aproximación

Una aproximación, similar a la que usa Fowler para definir el patrón, podría ser:

   1: public class UnidadDeTrabajo

   2:     {

   3:        

   4:         List<cBase> objetosNuevos;

   5:         List<cBase> objetosModificados;

   6:         List<cBase> objetosEliminados;

   7:  

   8:         public UnidadDeTrabajo()

   9:         {

  10:             objetosNuevos = new List<cBase>();

  11:             objetosModificados = new List<cBase>();

  12:             objetosEliminados = new List<cBase>();

  13:        }

  14:  

  15:         public void Añadir(cBase newObj)

  16:         {

  17:  

  18:         }

  19:  

  20:         public void Eliminar(cBase delObj)

  21:         {

  22:          

  23:         }

  24:  

  25:         public void Modificar(cBase modObj)

  26:         {

  27:             

  28:         }

  29:         public void Confirmar()

  30:         {

  31:             

  32:         }

  33:  

  34:         private void Limpiar()

  35:         {

  36:             objetosNuevos.Clear();

  37:             objetosModificados.Clear();

  38:             objetosEliminados.Clear();

  39:         }

  40:     }

Dentro de la definición de la clase podemos encontrar lo siguiente:

– Declaración de las listas que van a contener los objetos Nuevos, Modificados y Eliminados.

– Métodos para agregar los elementos Nuevos, los elementos modificados y los que serán eliminados.

– Método “Confirmar” que será el encargado de enviar los cambios a la Base de Datos.

– Método limpiar para vaciar las listas.

 

Las definiciones de los métodos están vacías, falta la lógica donde se va a comprobar si se deben o no añadir a la lista indicada el objeto deseado.

En el ejemplo estoy utilizando el tipo “cBase” que digamos es la clase base de cada una de las entidades de mi negocio.

A la hora de Confirmar los cambios, se podrían realizar las comprobaciones pertinentes para determinar que los datos no han sido modificados o eliminados por otro Usuario.

 

Conclusiones

El patrón UoW nos va a resultar muy útil a la hora de persistir un conjunto de acciones a ejecutar sobre la base de datos, evitando el exceso de conexiones contra la misma.

Se puede utilizar con la potencia de Entity Framework, por lo que es algo muy a tener en cuenta.

 

Saludos!

9 comentarios sobre “Patrón Unit of Work (UoW) o Unidad de Trabajo”

  1. Me dejan un poco mal sabor de boca tus posts y te explico el porque: Parace que cuentas lo que han escrito otros (Inglés/Español) sin aportar nada más, podrías haberte currado un ejemplo más amplio (No llega ni aproximación) vamos, que es un post de los que hace uno «pa meter paja» en el blog.

    Ánimo que pudes mejorarlo.

  2. Pues a mi me ha parecido claro y conciso, y es que el patron es complejo en sistemas avanzados y la mejor forma de mostrarlo es justamente reduciendolo a lo absurdo.

  3. vaya, vaya, me están suplantando !!! salu2grz

    siempre se pueden mejorar los posts, con ejemplos mucho mejor claro, pero hay que valorar el trabajo de los blogueros.

  4. Solo una pequeña anotación sobre los comentarios: lo que no queda claro es «evitando el exceso de conexiones contra la misma»
    No parece ser un objetivo de UoW.
    Además, UoW tiene una debilidad muy grande y es: ¿Qué pasa cuando tienes relaciones complejas en EF?
    En realidad UoW es una capa mas para hacer mas lento el acceso a datos abstrayéndose de la abtracción de EF (valga la redundancia).

  5. Bueno, en vista de las dudas planteadas mañana publicaré un nuevo post «más» explicativo, que espero satisfaga vuestras necesidades.

    @Vicente Gracias!

    @pregunton 1 si te parece que no aporto, espero que proximas aportaciones te interesen más, y en vista de que no eres el original, te agredecería que dejes de ser anonimo y te registres.

    @preguntoncojonero gracias por el comment.

    @paulo Gracias, en el proximo post espero que quede más claro ese comentario que puse.

  6. Este es un patrón muuuy pero muy útil. Siempre me ha extrañado el hecho de que, salvo los frameworks ORM, no se implemente más a menudo porque no solo aplica para el caso persistencia de objetos a una base de datos sino que puede usarse en todas aquellas ocasiones en que sea necesario hacer un seguimiento de los cambios que se van realizando en un conjunto de objetos con el fin de, una vez finalizadas, determinar cual debe ser el nuevo estado del sistema. Aunque si vamos al libro, solo lo expone para el caso de persistencia.

Responder a lontivero Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *