Archive
[Patterns] UnitOfWork
Este patrón se utiliza entonces para trabajar con un conjunto de objetos persistentes que deben tratarse como una "unidad" de trabajo, almacenandose en una base de datos de manera atómica. Este patrón es el encargado de trackear todos aquellos objetos que son nuevos, y que por lo tanto deben persistirse, todos los objetos que han sido modificados y que deben actualizarse en la DB y todos los que han sido borrados y deben quitarse de la base de datos.-
Agrega dos items más a la lista de items,
-
Modifica el importe y/o la cantidad de productos de uno de los items y finalmente,
-
Elimina uno de los item.
En este caso, cuando deben persistirse los datos? apenas agrega, modifica o elimina un item? o debe tratarse a la factura como una unidad y persistir todo junto? Si algo falla,… debe guardarse el resto? que sucede si otro usuario (además del que estamos hablando) estaba trabajando con el mismo documento al mismo tiempo pero guardó primero? como sabemos que fue lo que modificó el usuario y que, por lo tanto, debemos guardar? guardamos primero la factura y luego los items o al revés?
Todas las respuestas a estas preguntas (que considero que las fuiste contestando) se resuelven mediante la implementación de este patrón.
Voy a explicarlo un poco. El Unit Of Work, como se observa en la figura de arriba, se implementa mediante una única clase la cual tendrá al menos tres listas, una lista para los objetos nuevos que deben guardarse en la db, otra lista para los objetos que han sido modificados y que por lo tanto deben modificarse en la db y, otra lista para los objetos que deben eliminarse. Opcionalmente, o mejor dicho, según la implementación lo requiera, puede contener una cuarta lista para almacenar clones de los objetos que se traen desde la base de datos, de manera que antes de persistir un objeto pueda corroborar, mediante estos clones de los objetos originales, que los registros correspondientes no han sido modificados por otro usuario.
Una razón para leer el libro y no solo conformarse con este artículo es que Fowler hace un análisi exaustivo de este patrón (y de todos sus patrones), sus formas de implementar, cuando implementarlos, pros y contras y sobre todo, lo que a mi más me gustó fueron los distintos intentos por hacer esta clase lo más transparente posible para el programador. Así, por ejemplo, analiza la posibilidad de que todas las clases persistibles hereden de una clase base que automáticamente las registre como nuevas en el contenedor, que cuando se invoque el setter methos de una propiedad, esta notifique al UnitOfWork correspondiente para que la registre como dirty, etc. Personalmente estube probando esto y otras ideas como AOP, que no me convenció para nada, y extensions methods con los cuales le agrega m’etodos de persistencia a los objetos que heredaban de esa clase base.
En cuanto a AOP, no me convención porque las opciones eran todas muy feas, o usaba el .Net Profiling API con C++ para capturar la ejecución del JIT y entonces inyectarle código MSIL a los setters, o las clases heredaban de ContextBoundObject para, mediante los proxies de remounting, poder interceptar las invocaciones a las propiedades (lento, sucio, que más?) o, usando un compilador de terceros (no MS) casi en todos los casos en beta 0.000001. Así que definitivamente por el momento no lo ví como una opción.
En resumen, creo que es mejor, aunque un poquito mas tedioso y propenso a errores, dejar que sea el programador quien registre los objetos en el Unit of Work.
Acá dejo una implementación sencillísima de UnitOfWork sin control de concurrencias y en colaboración con un DataMapper trivial. Más abajo les dejo un proyecto que implementa esta clase.
using System; using System.Collections.Generic; using System.Text; using System.Transactions; using System.Data.SqlClient; using System.Configuration; using System.Threading; using System.Resources; namespace Patterns { // Nuestra clase UnitOfWork (Martin Fowler) public class UnitOfWork { // Aquí estan las tres listas de las que hablamos // Ademas de estas puede existir una cuarta que almacene // los objetos limpios (o que se leyeron de la db) List<IBusinessObject> newObjects; List<IBusinessObject> dirtyObjects; List<IBusinessObject> removedObjects; // Creamos las listas en este constructor public UnitOfWork() { newObjects = new List<IBusinessObject>(); dirtyObjects = new List<IBusinessObject>(); removedObjects = new List<IBusinessObject>(); } public void New(IBusinessObject bo) { Guard.NotNull(Resources.parameter_is_null, "bo", bo); Guard.IsTrue (Resources.object_is_dirty, dirtyObjects.Contains(bo)); Guard.IsTrue (Resources.object_is_deleted, removedObjects.Contains(bo)); Guard.IsTrue(Resources.object_is_already_inserted, newObjects.Contains(bo)); newObjects.Add(bo); } public void Remove(IBusinessObject bo) { Guard.NotNull(Resources.parameter_is_null, "bo", bo); if (newObjects.Remove(bo)) return; dirtyObjects.Remove(bo); if (!removedObjects.Contains(bo)) removedObjects.Add(bo); } public void Update(IBusinessObject bo) { Guard.NotNull(Resources.parameter_is_null, "bo", bo); Guard.IsTrue(Resources.object_is_deleted, removedObjects.Contains(bo)); if (!newObjects.Contains(bo) && !dirtyObjects.Contains(bo)) dirtyObjects.Add(bo); } // El método Commit es el encargado de iniciar las transacciones, // y realizar la invocación a la base de datos. public void Commit() { string connectString = string.Empty; using (TransactionScope transactionScope = new TransactionScope()) { connectString = ConfigurationManager.ConnectionStrings["Patterns"].ConnectionString; using (SqlConnection connection = new SqlConnection(connectString)) { try { // Construimos las sentencias SQL para luego pasárselas a la DB // mediante un command. Para esto, en .Net hay que hacerlo separando // las sentencias con un punto y como (;) StringBuilder stringBuilder = new StringBuilder(); foreach (IBusinessObject bo in newObjects) stringBuilder.Append(Mapper.Instance.Insert(bo) + ";"); foreach (IBusinessObject bo in dirtyObjects) stringBuilder.Append(Mapper.Instance.Update(bo) + ";"); foreach (IBusinessObject bo in removedObjects) stringBuilder.Append(Mapper.Instance.Delete(bo) + ";"); string command = stringBuilder.ToString(); // Abre la conexió, crea el comando con las sentencias SQL // e invoca al RDBMS. connection.Open(); SqlCommand command1 = new SqlCommand(command, connection); command1.ExecuteNonQuery(); // Limpia las listas si todo estuvo bien. ClearAll(); } catch (Exception ex) { System.Console.WriteLine("Exception Message: {0}", ex.Message); } } transactionScope.Complete(); } } private void ClearAll() { newObjects.Clear(); dirtyObjects.Clear(); removedObjects.Clear(); } } }
El proyecto: http://www.carloszanini.com.ar/shared/UnitOfWork.zip No esperen gran cosa. Gracias a Carlos Zanini por el hosting.
Lucas Ontivero
[Patterns] Lifetime Container Pattern
Muchas veces es necesario mantener el control del tiempo de vida de los objetos. En tecnologias de código administrado como .Net o Java, a diferencia de otros como C y C++, existe un mecanismo de recolección de basura que libera al programador de la tarea de destrucción de objetos y la liberación de la memoria. No obstante, existen ocaciones en las que tener el control de la destrucción de los objetos es muy conveniente.
Por ejemplo, cuando la creación de un objeto consume mucho tiempo y recursos del procesador, crear estos objetos y permitir que se destruyan cuando se pierden las referencia a él puede que no sea una buena idea, en este caso se opta por crear un pool de objetos que no se destruyan cuando ya no se usen sino que permanezan disponibles aún cuando no se los esté usando. Otra situación se da cuando se necesita liberar un conjunto de recursos (objetos) que ya no se van a utilizar más porque en su conjunto representan o sirven a una sola unidad de trabajo. Un caso concreto es cuando se utilizan objetos que administran gran cantidad de otros objetos también completos como los WorkItem del Composite UI Appication Block el cual mantiene colecciones de objetos Views, Controlers, Commands, EventTopics, Services, SmartParts, UIExtensionSites, WorkSpaces, otros WorkItems y algunas cosas más. En este caso, cuando se libera un workitem, se deben liberar todos los objetos que han colaborado con él.
El Lifetime container, como su nombre lo indica, es un contenedor (una colección) que mantiene vivas las referencias a todos los objetos que se registran en él. Vamos al código:
using System;
using System.Collections;
using System.Collections.Generic;
namespace Temosoft.Containers
{
public class LifetimeContainer : IEnumerable<object>, IDisposable
{
#region Private Fields
// El contenedor interno que mantiene vivas las referencias.
private List<object> items = new List<object>();
#endregion
#region Public Methods (Operations)
public void Add(object item)
{
items.Add(item);
}
public void Remove(object item)
{
if (!items.Contains(item))
return;
items.Remove(item);
}
public bool Contains(object item)
{
return items.Contains(item);
}
#endregion
#region Public Properties (Read only)
public int Count
{
get { return items.Count; }
}
#endregion
#region IDisposable interface
public void Dispose()
{
Dispose(true);
}
protected void Dispose(bool disposing)
{
if (disposing)
{
List<object> itemsCopy = new List<object>(items);
itemsCopy.Reverse();
foreach (object o in itemsCopy)
{
IDisposable d = o as IDisposable;
if (d != null)
d.Dispose();
}
items.Clear();
}
}
#endregion
#region Enumerators
public IEnumerator<object> GetEnumerator()
{
return items.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
#endregion
}
}
Como se puede ver, esta clase es muy parecida a una colección salvo porque implementa IDisposable para manejar la liberación de los objetos en orden inverso a su registración. No implementa ICollection porque en este caso no se debe posibilitar el método CopyTo() y porque en este caso, por razones de sencillez, no se hizo thread safe.
Como se ve, este es un contenedor sumamente sencillo y surge la pregunta "que hay de nuevo acá?", bueno, la verdad es que lo nuevo lo encontramos en la manera o las formas de usarlo. Veamos, en la entrada de este blogs: [Patterns] Distributed Applications using FactoryMethod and ServiceLocator Patterns, vimos como la clase ServiceLocator mantenia un diccionario de strings y objetos (después lo hicimos mediante object-object), este diccionario impide que los servicios que no se utilizan puedan ser eliminados! Como podemos manejar esto con un LifetimeContainer? la respuesta es NO mantener las referencias. Esto lo podemos hacer implementando el ServiceLocator mediante un weakRefDictionary<object, object> en lugar de un Dictionary<object, object>.
public class ServiceLocator
{
private WeakRefDictionary<object, object> services = new WeakRefDictionary<object, object>();
public void AddService(object serviceKey, object service)
Que beneficios nos trae esto? Ahora, cada componente, plugin, unit of work, form, o lo que sea puede registrar sus servicios, de manera que estén disponibles para todas los demas componentes, mientras dure su vida y que dejen de estarlo cuando ellos son destruidos (a menos que alguien los esté usando). Por lo tanto, cada componente tiene su propio Lifetime container para manejar el ciclo de vida de SUS objetos.
Lucas Ontivero
[Patterns] Distributed Applications using Facade Pattern
Este patrón tan sencillo es seguramente uno de los más importantes en el desarrollo de aplicaciones que publican sus servicios mediante Web Services. El motivo de este post es ayudar a entender la forma correcta de implementar Web Services con .Net.
El problema
Afortunadamente hoy contamos con muchas herramientas y facilidades para la creación y publicación de servicios web. En .Net, es increiblemente facil crear un servicio web a partir de una clase, solo hay que extender nuestra clase de la clase System.Web.Services.WeServices y adornar el o los metodos que queremos publicar con [WebMethod] y listo. Por ejemplo:
using System;
using System.Web.Services;
public class HelloWorld: WebService {
[WebMethod(Description="Returns Hello", EnableSession=false)]
public string Say() {
return "Hello";
}
}
El problema con estas facilidades es que muchos desarrolladores entienden que el objetivo de esto es exponer en el cliente, proxies mediantes, los objetos de negocios que se encuentra en el servidor. Esta creencia promueven un mal estilo de programación de los servicios web. Es más, no son servicios ya que se parecen mas a llamadas RPC o RMI. Esto es un error. No deben exponerse los objetos de negocio mediante un WebService.
Un escenario real: En un desarrollo para una empresa de reservas de hoteles, teniamos las clases Hotel, Habitacion, Reserva, Pasajero, Temporada y otras más. Un amigo se encargaba del desarrollo del cliente y sus necesidades eran claras, "necesito una lista con las disponibilidades (con los dias disponibles) y precios de las habitaciones de los hoteles en esos dias y la descripción de las comodidades o servicios que incluyen en esa temporada". Este y otros requerimientos no se corresponden con ningún objeto del negocio, es decir, sencillamente no se resuelven serializando y enviando ningún objeto del negocio.
La solución
La solución consiste en crear un Facade cuyos métodos representen los servicios que puede brindar la aplicación como por ejemplo: obtener disponibilidades de tal fecha a tal fecha para tantas personas en determinado sitio turístico, obtener nuevas reservas para un hotel determinado, reservar, cancelar reserva, etc.
Ahora, por lo general los métodos del Facade no tendrán problemas en cuanto a los tipos de parámetros a recibir ya que serán (repito, por lo general) tipos simples como int, DateTime, String, Boolean, Double, etc. Pero sí requerirán retornar al cliente tipos especiales que, como dije antes, no se corresponden con los objetos de negocio. Entonces esto ya no es una simple clase "ReservationFacade" sino que se trata de un componente (o layer) con sus propios tipos como Availability, Recommend, etc. Si bien estos tipos pueden, por sus nombres, parecer que pertenecen a los tipos del dominio en realidad no lo son. Por ejemplo, Recommend puede contener un destino o zona turística recomendada junto con una lista de ofertas de tipos de habitaciones con sus precios en distintos hoteles y los periodos de validez de estas recomendaciones.
Ventajas de este patron:
- Facil de responder a los cambios. Si el Web Service debe modificarse para ajustarse a los nuevos requerimientos del negocio entonces solo es necesario modificar el Facade.
- Facil de mantener. Es posible modificar la estructura interna (refactoring) de las clases de negocio sin alterar el contrato con los clientes de WS. Ya que no se crean dependencia entre las clases de negocio con las aplicaciones clientas.
- Responde a la idea de servicios. Los servicios se consumen en operaciones atómicas. Es decir, el servicio de "Reservar habitación" se realiza mediante un solo mensaje con toda la información necesaria y es el Facade quien se encarga de realizar todas las operaciones (seguramente en una transacción).
- Son mas veloces. Por la misma razón que expongo arriba se realizan muchas menos idas y vueltas desde el servidor al cliente y viceversa.
La ventaja quizás mas importante es independizar el WS del resto de la aplicación ahorrandonos de tener que regenerar el WS (salvo cuando tocamos el Facade) y por lo tanto evitamos tener que regenerar los proxies en todos los cliente de nuestro WS y recompilar todo, tanto nosotros como todos nuestros clientes que pueden estar utilizando nuestros servicios somos más felices.
Otra ventaje que se deriva del punto anterior es que el versionado de nuestro servicio se simplifica considerablemente.
Lucas Ontivero
[Patterns] Distributed Applications using FactoryMethod and ServiceLocator Patterns
En esta entrada vamos a ver la utilidad del patrón Service Locator para construir aplicaciones distribuidas. Los componentes de estas aplicaciones deben estar totalmente desacoplados y por lo tanto la mejor manera de hacerlo es mediante el consumo de servicios que obviamente respeten ciertos contratos.
Ok, largamos con el patrón FactoryMethod como patrón inicial para ver como llegamos al ServiceLocator. Entonces, basicamente, todo método que tiene por objetivo crear diferentes tipos de objetos implementa implementa el patrón FactoryMethod. Veamos un ejemplo:
1 using System.Windows.Forms;
2
3 namespace MyDocumentManager
4 {
5 enum DocumentExtensionEnum {DOC, PDF, XML};
6
7 /* La clase Abstracta */
8 public abstract class Document
9 {
10 public abstract void Show(Form container);
11 }
12
13 /* Las clases concretas */
14 public class WordDocument : Document
15 {
16 public override void Show(Form container){/*...*/}
17 }
18
19 public class PDFDocument : Document
20 {
21 public override void Show(Form container){/*...*/}
22 }
23
24 public class XMLDocument : Document
25 {
26 public override void Show(Form container){/*...*/}
27 }
28
29 /* La clase creadora o consumidora de documentos */
30 public class DocumentManager
31 {
32 DocumentManager(string filename)
33 {
34 Document doc = FactoryMethod(filename);
35 doc.Show(new DocumentViewerForm());
36 }
37
38 /* Este es el metodo */
39 private Document FactoryMethod(string filename)
40 {
41 Document doc;
42 DocumentExtensionEnum extension = GetExtension(filename);
43
44 /* crea el tipo de documento adecuado segun la extension del archivo */
45 switch(extension){
46 case DocumentExtensionEnum.DOC:
47 doc = new WordDocument();
48 break;
49 case DocumentExtensionEnum.PDF:
50 doc = new PDFDocument();
51 break;
52 case DocumentExtensionEnum.XML:
53 doc = new XMLDocument();
54 break;
55 }
56 retrun doc;
57 }
58 }
59 }
60
Este es un ejemplo claro, según la extensión del archivo, nos devuelve el objeto adecuado. El tema es ahora que en este método tenemos un switch hardcodeado! Es decir, no podemos agregarle otros tipos de objetos a crear sin modificar el código 😦
Y aquí entra el patrón que nos convoca, el Service Locator. Se trata de un patrón creational el cual permite registrar servicios o componentes y luego solicitar una instacia de alguno de ellos. Veamos un poco de código:
public class ServiceLocator
{
private Dictionary<string, object> services = new Dictionary<string, object>();
public void AddService(string serviceName, object service)
{
if (string.IsEmptyOrNull(serviceName))
throw new ArgumentNullException("serviceName");
if (service == null)
throw new ArgumentNullException("service");
services.Add(serviceName, service);
}
public object GetService(string serviceName)
{
if (string.IsEmptyOrNull(serviceName))
throw new ArgumentNullException("serviceName");
if (services.ContainsKey(serviceName))
return services[serviceName];
return null;
}
}
Aquí lo he implementado con un diccionario string-object para hacerlo mas facil pero despues voy a mostrar una alternativa mejor. Otra cosa, por lo general, solo existe una instancia de esta clase as’i que se implementa mediante un Singleton.
La ventaja que tenemos ahora es que podemos hacer una clase "Services Loader" la cual lea un archivo de configuración (seguramente deserealizando un xml) y que de acuerdo a eso cargue los servicios que hagan falta dentro del Service Locator. Esto es especialmente útil cuando queremos hacer un sistema plug-able porque podemos poner un assembly en un directorio y modificar nuestro xml de configuración de modo que esta clase Service Loader cargue ahora los nuevos servicios de nuestro assembly haciendo que estos esten disponibles para la aplicación.
A ver si se entiende bien! puedo por ejemplo:
IStorageManager sm = (IStorageManager)serviceLocator.GetService("Storage Service");
if(sm != null)
{
sm.Save(myPersistentObject);
}
else
{
IEventLogger ev = (IEventLogger)serviceLocator.GetService("Event Logger Service");
if(ev != null)
ev.WriteWarning(
String.Format("{0} wasn't persisted", myPersistentObject.ToString()
);
}
Bien, alguno debe estar pensando "y como hace un cast así! habria que validar que respete esa interface antes de castearla tan burramente!!!". Y sí, quien piesa así tiene razón, el tema es que lo hago así por sencilles y porque lo que quiero mostrar es que de esta manera lo que hacemos es: primero preguntamos si tenemos tal o cual servicio y de ser así lo usamos. Con este patrón (que todavia no tiene buena forma) podemos agregarle, sin tocar el código, un servicio de logueo cualquiera (que implemente la IEventLogger por supuesto). También podemos ponerle, sacarle o cambiarle el servicio de Storage registrando por ejemplo bajo el nombre de "Storage Service" a cualquier servicio que implemente la interface IStorageManage como por ejemplo, "SQL Storage Service", "Amazon Storage Services", "Web Blog Storage Service", etc.
Tanto que hablamos del "Service Loader" veamos como puede ser:
(Antes que nada, si ven algo que no anda es porque en la máquina en que estoy escribiendo esta entrada no tengo el .Net Framework 2.0)
[XmlRootAttribute("ServiceCatalog", Namespace="http://www.temosoft.com.ar/ServiceLoader", IsNullable = false)]
public class ServiceCatalog
{
private Service[] services;
public Service[] Services
{
get{ return services; }
set{ services=value; }
}
}
[Serializable]
public class Service
{
private string serviceName;
private string assemblyName;
private string typeName;
private Boolean isAvailable;
[XmlAttribute]
public string ServiceName
{
get { return serviceName; }
set { serviceName= value; }
}
[XmlAttribute]
public string AssemblyName
{
get { return AssemblyName; }
set { AssemblyName= value; }
}
[XmlAttribute]
public string TypeName
{
get { return typeName; }
set { typeName= value; }
}
[XmlAttribute]
public Boolean IsAvailable
{
get { return isAvailable; }
set { isAvailable= value; }
}
}
public class ServiceLoader
{
public void Load()
{
XmlSerializer serializer = new XmlSerializer(typeof(ServiceCatalog));
FileStream fs = new FileStream("ServiceCatalog.xml", FileMode.Open);
ServiceCatalog servicesCatalog = (ServiceCatalog)serializer.Deserialize(fs);
foreach(Service s in servicesCatalog.Services)
{
try{
Assembly asm = Assembly.Load(s.AssemblyName);
Type serviceType asm.GetType(s.TypeName);
ServiceLocator.Instance.AddService( s.ServiceName, Activator.CreateInstance(serviceType));
}catch(Exception e){
}
}
}
}
En este caso asuminos que el ServiceLocator es un Singleton. Es posible también hacer que cada servicio pueda recibir parámetros en su constructor. Ahora, como hacemos para mejorar esto?
public static class ServiceLocator
{
private static ServiceLocator instance;
private static object instanceLock = new object();
private Dictionary<object, object> services = new Dictionary<object, object>();
public ServiceLocator Instance
{
get
{
if (instance == null)
{
lock (instanceLock)
{
if (instance == null)
{
instance = new ServiceLocator();
}
}
}
return instance;
}
}
public void Add(object serviceKeyObject, object service)
{
if (serviceKeyObject==null)
throw new ArgumentNullException("serviceKeyObject");
if (service == null)
throw new ArgumentNullException("service");
if (!services.ContainKey(serviceKeyObject))
services.Add(serviceKeyObject, service);
}
public object Get(object serviceKeyObject)
{
if (serviceName==null)
throw new ArgumentNullException("serviceKeyObject");
if (services.ContainsKey(serviceName))
return services[serviceName];
return null;
}
public T Get<T> (object serviceKeyObject)
{
object obj = Get(serviceKeyObject);
if (obj != null && (obj is T))
return (T)obj;
return null;
}
}
Si no te sirvió usa el ObjectBuilder 🙂 ,que además de implementar este y otros muchos patrones muy grosos, implementa Inyección de Dependencias para un desacople muy bien pensado.
Lucas Ontivero.
Booteando ando 