Command

Este patrón encapsula la solicitud para ejecutar una tarea como un objeto de manera tal que el componente que solicita la ejecución (Invoker o Actor) desconoce los detalles y dependencias necesarias para ejecutar la tarea (Command o Acción). Una vez que el comando se crea y se asigna al Invoker, el Invoker puede solicitar la ejecución del Command en otro momento y no necesariamente en el momento en el que se crea un Command.

Cuando se crea una instancia de una clase que implementa la interfaz Command se le proporciona el(los) objeto(s) necesarios para ejecutar el comando (Receiver(s)). Es decir,  una vez creado el Command, éste incluye todas las dependencias necesarias para ejecutar la acción o tarea (esto es una consecuencia de que el/los método(s) en la interfaz Command no incluyen parámetros).

Entonces, el patrón permite la ejecución de una tarea de manera tal que los siguientes aspectos quedan separados:

• La solicitud de ejecución de una Acción realizada por un Actor vs. de la ejecución de la Acción.
• La creación de la solicitud de ejecución de una Acción vs. el momento en el que efectivamente se ejecuta.

Unit of Work

Este patrón tiene como objetivo consolidar aquellos objetos nuevos, modificados o eliminados en un proceso de negocio de manera tal que todos los cambios pendientes en el repositorio de datos se realicen como una unidad.

Algunos frameworks de persistencia ya incorporan este patrón en los mecanismos que proveen; por ejemplo, una instancia que implementa la interfaz EntityManager de un proveedor JPA hace un seguimiento a los cambios realizados en las entidades que gestiona para generar un serie de sentencias SQL que permiten sincronizar el estado de los objetos con la BD relacional.

Finalmente, se trata de una aplicación del patrón Command donde las tareas (Commit y Rollback) y  las dependencias para realizarla están explícitamente definidas.

Referencias

[1] Design Patterns: Elements of Reusable Object-Oriented Software

[2] Unit of Work

[3] Unit of Work: Ejemplo