Lucas Ontivero

Cita

Patron Factory Method 1

  
Video: Patron Factory Method 1

Rodrigo Corral me ha invitado a formar parte de Geeks.ms y he aceptado con gusto su propuesta. Es por esto que no voy a escribir más en este espacio y los invito a que se subscriban a mi nuevo blog en http://geeks.ms/blogs/lontivero .

Saludos a todos.

Lucas Ontivero

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

var contact = {
     "Name": "John Doe",
     "PermissionToCall": true,
     "PhoneNumbers": [ 
       {
           "Location": "Home",
           "Number": "555-555-1234"
       },
       {
           "Location": "Work",
           "Number": "555-555-9999 Ext. 123"
       }
     ]
};

{"Name": "John Doe", "PermissionToCall": true, "PhoneNumbers": [{"Location": "Home", "Number": "555-555-1234"}, {"Location": "Work", "Number": "555-555-9999 Ext. 123"}]

xmlhttp.open("GET","/personnel/find?id=26481648",true);
xmlhttp.onreadystatechange=function() {
    if (xmlhttp.readyState==4) {
        if (xmlhttp.status!=404) {
            var employee=new Function("return "+xmlhttp.responseText)();
            alert("DNI : " + employee[0].dni+' - Full Name : '+ employee[0].fullname);
        } else {
            alert("Employee not found");
        }
    }
}

• donde encaja JSON en un WS si estos utilizan XML?,
• Si quisiera utilizarlo, como serializo mis objetos? tengo que hacer mi propio serializador?

La verdad es que la serialización no es un problema, existen muchos Framework para trabajar con JSON en .Net (Jayrock por ejemplo) los cuales son generalmente muy pequeños, fáciles y trabajan muy bien (por los comentarios en distintos sitios). También, para los que trabajan en ASP.NET está la implementación de AJAX "Serialization.JavaScriptSerializer".

En cuanto a los WSs, la única restricción real es que debe transmitir texto dentro de un sobre SOAP y nada más.

Algunos link muy interesantes:

• JSON web site (en castellano)
• An Introduction to JavaScript Object Notation (JSON) in JavaScript and .NET (completísimo, muy bueno y por gente de MS)
• The B-List : I can't believe it's not XML! (muy buen artículo - explica muy bien el por qué JSON es una buena opción)
• The JSON vs XML debate begins in earnest (discusión y comparación entre JSON y XML pros y contras - de alto vuelo)
• MSDN Magazine: Client-Side Web Service Calls with AJAX Extensions (Algo práctico con ASP.NET)
• Using JSON (JavaScript Object Notation) with Yahoo! Web Services (Otro ejemplo práctico - consumir WS de Yahoo - compara XML y JSON)
• Silverlight and JSON (No lo leí pero dice "Silverlight 1.1 comes with an built-in JSON serializer which can..." )

Lucas Ontivero

[Tanslate this post to english with google]

He creado un nuevo blog dedicado a todo lo referido a software-factories, patrones, metodologías y todo lo que esté orientado a incrementar la calidad, la productividad y el tiempo de entrega de los productos de software. Seguramente también incluiré algunas ideas y/o traducciones de artículos interesante. Ya he pasado algunos post de este blogs al nuevo. Véanlo en http://software-factories.blogspot.com/ 

Saludos.

Lucas Ontivero

 

En un Pentium 4 de 2.8GHz y 1 GB de RAM / Windows XP PE SP2.

using System;
using System.Text;
using System.Reflection;

namespace Temosoft.Benchmarks
{
        class Program
        {
                static void Main(string[] args)
                {
                        DateTime startDate;
                        TimeSpan ts;
                        int max = 10000000; //int.MaxValue;

                        TestClass t = new TestClass();

                        System.Console.WriteLine("----- FIELDS ------");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.field = i;
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.field = i;", ts.Ticks);


                        Type type = typeof(TestClass);
                        FieldInfo fi = type.GetField("field");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                fi.SetValue(t, i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "fieldInfo.SetValue(t, i);", ts.Ticks);


                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                typeof(TestClass).GetField("field").SetValue(t, i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "typeof(TestClass).GetField(\"field\").SetValue(t, i);", ts.Ticks);


                        System.Console.WriteLine("----- PROPERTIES --");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.Field = i;
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.Property = i;", ts.Ticks);


                        PropertyInfo pi = type.GetProperty("Field");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                pi.SetValue(t, i, null);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "propertyInfo.SetValue(t, i);", ts.Ticks);


                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                typeof(TestClass).GetProperty("Field").SetValue(t, i, null);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "typeof(TestClass).GetProperty(\"Field\").SetValue(t, i, null);", ts.Ticks);


                        System.Console.WriteLine("----- METHODS --");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                t.Method1(i);
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "obj.Method(i);", ts.Ticks);


                        MethodInfo mi = type.GetMethod("Method1");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                mi.Invoke(t, new object[]{i} );
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "methodInfo.Invoke(t, new object[]{i} );", ts.Ticks);


                        mi = type.GetMethod("Method2");
                        startDate = DateTime.Now;
                        for (int i = 0; i < max; i++)
                        {
                                mi.Invoke(t, new object[] { i, i, i, i, i, i });
                        }
                        ts = DateTime.Now.Subtract(startDate);
                        System.Console.WriteLine("{0, -42}: {1}", "methodInfo.Invoke(t, new object[] { i, i, i, i, i, i });", ts.Ticks);

                        System.Console.ReadLine();
                }
        }

        class TestClass
        {
                public int field;
                public int Field
                {
                        set { field = value; }
                        get { return field; }
                }

                public void Method1(int i)
                {
                        field = i;
                }

                public void Method2(int i, int j, int k, int l, int m, int n)
                {
                        field = i;
                }

        }
}

Lucas Ontivero

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

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

 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 

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.

Ok. Esta es la parte dos de la introducción.

Realmente no quería caer en el mismo ejemplo de libro pero lo voy a hacer. La manera en que hoy desarrollamos software es exactamente igual a como se hacian los automóviles antes de Mr. Ford. Como era esto? Bueno igual que lo que hacemos hoy, venia un cliente y decía: quiero una auto así, así y así con madera de pino de Groenlandia, cuero de jaguareté y pedales de tutú carreta, entonces se diseñaba el auto de cero, a alguno se le ocurria que lo mejor era un rodado de marfil y aluminio de 23,67 pulgadas, etc. Una vez listo el diseño se ponian con los cerruchos, martillos, un tornito y otras herramientas y en 6 o 7 meses estaba listo. Salian mas o menos bien y costaban caro. Hoy en cambio todos los autos comparten un gran número de componentes comunes entre otras cosas gracias a los estandares. Son estos lo que me permiten enchufar mi televisor en cualquier parte del pais y que siga funcionando o cambiar el cuerito de la grifería sin tener que averiguar medidas.

Esta forma de trabajo se caracteriza por:

• Uso intensivo de la mano de obra,
• Uso de herramientas demasiado genéricas,
• Mínimo reuso y, 
• Procesos genéricos

De esta manera se producen demoras en los tiempos de entrega, defectos, agujeros de seguridad y retrabajos. Además de imposibilitar la introducción de calidad desde el primer momento en cuanto a aquellos detalles diferenciadores como seguridad, usabilidad, desempeño, mantenibilidad y escalabilidad de los productos (sin causar fatigas por falencias en la arquitectura) entre otros.

Antes de continuar analizando los por qué del surgimiento de este paradigma vamos a definir algunos términos que son muy necesarios como por ejemplo el de Software Factory y luego voy a aclarar algunas cosas que me quedaron en el tintero del post anterior.

Definiciones

Software Factory

Si se le hubiese llamado de otra manera nos habriamos visto forzados a realizar un esfuerzo mental para averiguar y tratar de entender de que se trata este concepto pero desgraciadamente esta palabrita "Factory" nos habilita a pensar cualquier cosa. Las analogías que encontramos por todos lados con fabricas de zapatos o electrodomésticos terminan de confirmar nuestras fantasias mal fundadas. No son pocos los que creen que se trata de hacer software como si de automoviles se tratara, simplemente ensamblando algunas partes hechas en una linea de montaje y automatizando, robots mediantes, los detalles como el color de la pintura y otros. Bueno, no es así. La figura que adorna este post también confunde pero está muy buena para reflejar el estado actual del arte :)

Distingamos entre Software Factory como paradigma y como instancia. Como paradigma, es una alternativa a los métodos actuales de construcción que intenta resolver los 5 problemas planteados en el post anterior cuando las aplicaciones a construir comparten características comunes. Como instancia (SCSF por ejemplo), un Software Factory es un conjunto de herramientas, procesos tailorizados, frameworks, patrones y modelos (por lo general embebidos en los frameworks y/o herramientas integradas del IDE) y otros contenidos que usan para trabajar sobre una Linea de Productos. O mejor dicho, un SF es una linea de producto que utiliza un SF Template basado en un SF Schema.

Linea de Productos

Una linea de productos se refiere a un tipo de aplicación que puede agruparse o identificarse como perteneciente a una familia de productos como por ejemplo sistemas de CRM, software de seguros, software para entidades bancarias, de control aereo y cualquier otro. Es decir, pueden agruparse de distintas maneras, por segmento de negocios, tipo de soluciones, plataforma, etc. Lo importante es poder identificar aquellas características comunes. Tres aspectos claves de una linea de productos son: los alcances, la variabilidad y la extensibilidad. Los alcances determinan que tipo de soluciones pueden construirse a partir de la linea de productos y define por lo general la arcitectura base para la familia de aplicaciones, la variabilidad hace referencia a las parte comunes definidas en los alcances y aquellas que son variables por medio de configuración de la linea y la extensibilidad determina los puntos en los que es posible añadir funcionalidades.

Software Factory Schema

Un Software Factory Schema es un modelo general que por lo general utiliza grillas, gráficos o cualquier otro artefacto para describir cuales son los productos de trabajo, los pasos a seguir para construirlos, las relaciones existentes entre ellos. Esta es una herramienta para entender y posiblemente automatizar el funcionamiento del SF. Por ejemplo, un SF Schema puede describir los paquetes que se utilizan, la distribución f'isica de los componentes y como los distintos miembros de los equipos se relacionan con cada uno de estos aspectos. Un SF Schema se compone de Viewpoints que no son otra cosa que la descripción de todos los assets que intervienen en la generación de un aspecto del software que se desea desarrollar. Por ejemplo, un view point para la creación de un smart client podría ser la generación de la UI, en este caso el view point especificaría el conjunto de cosas necesarias para realizarlas, desde una clase base Form, diseñadores, DSL para especificar la navegabilidad entre formularios, herramientas de generación de algunos aspectos o plantillas, guias necesarias que intervienen es este punto, etc. Podría decirse que es la colección de todos los puntos de vista de un SF o el plano conceptual de este. Este plano tiene forma de arbol y cada rama trata un aspecto particular de la solución que a su vez se divide en otras ramas que los analizan desde otros puntos de vista. La definición de Viewpoint de la IEEE está en IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.

Software Factory Template

Una vez que tenemos los planos conceptuales del Software Factory que queremos construir debemos.... construirlo!! Es decir, ya sabemos que assets necesitaremos, como serán, donde intervendrán, como se relacionarán, etc. Ok, ahora hay que hacerlos. Esto es, crear los frameworks, las guias, los asistentes, los DSLs, procesos y todos los demás asstes descritos en el esquema he integrarlos (en lo posible) al IDE. Cada vez que se construye un nuevo producto, cada desarrollador puede (y debería) contribuir con el SF añadiendo sus plantillas, snippets, instructivos, frameworksy cualquier otro asset. Para más información acerca de estos últimos dos temas les recomiendo la edición número 9 de la revista The Architecture Journal y en especial el artículo de Tom Fuller "Fundamentos para los pilares de las Fábricas de Software".

Lo que me quedó en el tintero

Algo que me quedó en el tintero es el tema de las metodologias cuyo problema resumia como "o (son) muy formales o (son) uy ágiles". Greenfield  y Short  plantean (lo que a muchos nos parece obvio) que existen dos tendencias extremas con sus pros y contras. A diferencia de lo que uno podría esperar, Greenfield  y Short no creen que una metodología más formal sea más MADURA, por el contrario, entienden que son inmaduras por extremistas.

En cuanto a los desarrolladores

Luego vamos a ver como distinguen entre "tipos" de desarrolladores (este "tipos"