Lucas Ontivero : C#

Design patterns in the test of time: VISITOR

Lucas Ontivero — Tue, 30 Oct 2012 04:46:00 GMT

@Ayende ha comenzado una serie de post en lo que revisa algunos patrones de diseño (Go4) luego de transcurridos más de 18 años desde su formalización en el libro Design Patterns: Elements of Reusable Object-Oriented Software. Inspirado por esa serie, y por el hecho de que en mi última entrevista laboral me preguntaron sobre esto, voy a presentar una revisión sobre el patrón visitor.

Visitor en su forma clásica

La motivación detrás de este patrón es poder añadir funcionalidad a una estructura de datos sin necesidad de modificar las clases que conforman esa estructura. En otras palabras: separar las estructuras de datos de aquellos algoritmos que operan sobre ellas. Si vamos a la Wikipedia vamos a ver este diagrama:

Technorati Tags: Design,Pattern,Visitor

Como se ve, tiene referencias cíclicas, es decir, todos los CarElements deben implementar un método accept que recibe una referencia a un CarElementVisitor y todo CarElementVisitor matiene referencias a todos los tipos que implementan la interface CarElement. Esto es porque C# (el diagrama usa java) no posibilida doble dispatch y así, mediante estas referencias cíclicas es cómo se logra simularla.

Aparte del fuertísimo acoplamiento al que nos fuerza, tiene el inconveniente de ser un patrón que agrega bastante complejidad y que es poco legible debido a su “extraña” sintaxis. Así, si tuviésemos un AST y quisiésemos volverlo código mediante un visitor, nuestro código se vería así:

Pero si tratamos de seguir este código, y vamos directamente a la implementación de este método ‘Accept’ nos encontraremos con esto:

Y por último, si nos salteamos la abstracción IVisitor y vamos directamente a la implementación del método Visit del PrinterVisitor, nos encontramos con esto otro:

Si no conoces el patrón, posiblemente no comprendas este código (y tengamos en cuenta que nos hemos salteado las abstracciones!). Pero el motivo más frecuente por el que no se entiende, si es ese el caso, es porque es complejo.

Visitor alternativo

La propuesta que dejo no es mia, ni es nueva. Esta es una implementación muy popular en lenguajes dinámicos.

Partamos del mismo supuesto: tenemos un AST al que queremos transformar en un string. Lo primero que podemos cambiar es la sintaxis confuza del visitor clásico mediante el uso de un Extension Method, como sigue:

Ahora veamos cómo se ven los nodos de este árbol:

Si bien aquí tenemos una interface INode la cual no luce muy bien, la simplicidad de los nodos es evidente ya que no estamos forzando a implementar ningún método extraño, me refiero al método ‘Accept’. Peo vamos a ver la implementación:

Esta implementación es mucho menos compleja y legible, además de reducir notablemente el acoplamiento (los nodos no necesitan conocer al IVisitor ni implementar ningún método extra) lo que posibilita eliminar las referencias cíclicas.

Lucas Ontivero

C# Closures y tipos anónimos a la Javascript

Lucas Ontivero — Thu, 24 May 2012 05:13:28 GMT

Es C# realmente dinámico? Si hace Cuac es un pato, si hace lo mismo que un lenguaje dinámico es dinámico. Qué te dice este código:

Nivelando para abajo

Lucas Ontivero — Thu, 24 May 2012 03:44:00 GMT

Leía este post de Luis Ruiz Pavon acerca del comportamiento de los closures en el que Luis anima a responder cual es la salida de un bloque de código en el que se devuelve un array de expresiones lambdas que referencian a la variable utilizada para iterar dicho array (closures) y entonces veo este comentario de Eduard Tomàs i Avellana:

El link al que referencia Eduard pertenece al blog de Eric Lippert: Closing over the loop variable considered harmful, una vieja entrada que había leído en su oportunidad pero que desestimé porque nunca pensé que llegara a tomarse la decisión de introducir un breaking change en el lenguaje para solucionar algo que NO ESTÁ ROTO, repito, NO ESTÁ ROTO.

Está claro que introducir este tipo de cambios no le gusta a nadie, y que por lo tanto debe de haberse meditado, y mucho. Pero ¿qué es lo que anima semejante cosa? Es decir, si vamos a romperle el código a muchos programadores es porque pensamos que es lo mejor para todos, ¿o no?

Veamos, ¿quiénes pueden verse afectados? de seguro todos aquellos que entiendan lo que son los closures y comprendan el scope de las variables y, ¿quienes pueden verse beneficiados? pues todos aquellos que no entienden esto. Y es por eso que estoy en desacuerdo, porque lo que se intenta una vez más es hacer que el lenguaje sea el guardián de la correctitud del software y no el desarrollado.

En mi experiencia, es absolutamente imposible defenderse de un desarrollador que no sabe lo que hace.

[Video] Serie sobre excepciones – Explicando ejemplo del MSDN

Lucas Ontivero — Fri, 20 Jan 2012 06:00:07 GMT

En este video explico el por qué un ejemplo tomado del MSDN está mal y cómo debería de escribirse en cuanto a la manera en que trata las excepciones.

Excepciones – Un caso sobre los ejemplos del MSDN

Lucas Ontivero — Fri, 20 Jan 2012 05:25:31 GMT

Soy un convencido de que muchos de los malentendidos que existen en cuanto al manejo de excepciones en VB.Net y C# es por culpa de los malos ejemplos que siempre ha tenido el MSDN. Con solo invertir un par de segundos en google uno puede encontrar verdaderas aberraciones.. A modo de ejemplo solo pondré dos links y las capturas:

http://msdn.microsoft.com/en-us/library/system.net.dns.resolve(v=vs.110).aspx
Si Bien es cierto que los ejemplos han mejorado muchísimo, porque años antes eran un desastre, todavía siguen existiendo demasiados de estos ejemplos, ejemplos que son tomados por muchos desarrolladores como “bunas prácticas” ya que provienen de un sitio de la más alta confianza.

Otro ejemplo: http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient(v=vs.110).aspx. Hay tantas cosas mal en este que da para pensar si estos ejemplos ayudan a los programadores o si por el contrario, los perjudica.

[Video] Serie sobre excepciones–Donde capturarlas

Lucas Ontivero — Tue, 20 Dec 2011 01:47:03 GMT

Les dejo la tercera entrega de la serie sobre excepciones.

Saludos

Retoques a MVC y Razor para proyectos grandes–Una recomendación

Lucas Ontivero — Sat, 17 Dec 2011 22:28:32 GMT

Luego de revisar los requerimientos de la aplicación en la que vengo trabajado estos últimos 6 meses, tuve que pensar cómo plantear la arquitectura de la misma teniendo en cuenta lo siguiente:

La aplicación es muy muy muy grande, eso era lo primero que saltaba a la vista en los requerimientos. Al día de hoy, esta cuenta con 1.119 vistas, 797 controladores y un número similar de modelos, entre otras cosas.
El equipo iba a ser grande y la idea era que trabajaran lo más focalizados posible en sus casos de uso y luego integrarlos para evitar fricción de dependencias entre los diferentes casos de uso.
La aplicación tiene módulos que agrupan sub-módulos y estos a su vez agrupan casos de uso. Los casos de uso eran bastante similares por lo que era también de esperarse que tuviesen una estructura similar entre ellos. Esto es: Vistas con idénticos o similares nombres como así también controladores y modelos similares los cuales podían también tener el mismo nombre.
El esquema de seguridad se basa en perfiles de usuarios los cuales tienen permisos sobre distintas operaciones sobre cada uno de esos casos de uso.

Con eso en mente, era evidente que el esquema por defecto de MVC (usando Razor) no era el adecuado ya que, por defecto, este agrupa las vistas en la carpeta Views, controladores en la carpeta Controllers y modelos en la carpeta Models. Es muy difícil de trabajar en un sistema grande con esta estructura; es a todas luces insuficiente ya tener 1.119 vistas en una sola carpeta presenta muchos problemas no solo a la hora de encontrar un archivo sino que además obliga a que no existan dos vista con el mismo nombre y eso era algo que el proyecto necesitaba tener realmente.

De no plantear una estructura de módulos, sub-módulos y casos de uso adecuada a las necesidades del proyecto este iba a ser un desastre, así que así lo hice. Para esto extendí dos componentes: ControllerFactory y RazorViewEngine.

Antes de comenzar, y para que vayan dándose una idea, nuestro esquema de mapeo en el Global.asax es el siguiente:

Y nuestra estructura de carpetas es la que sigue:

El ControllerFactory (simplificado para este blog) se ve más o menos como figura abajo y nos permite tener clases controladores con el mismo nombre pero con distinto namespace:

Por otro lado, la organización de las vistas en carpetas módulo/sub-módulo/casodeuso/ se logró extendiendo la clase RazorViewEngine que es la encargada de resolver la ruta donde se deben buscar las vistas cuando desde un controllador se lo solicita. El código de la clase puede verse abajo:

Con esto no solo se logra que las vistas se busques en la carpeta propia del caso de uso al cual pertenecen sino que además el orden de búsqueda permite que si una vista, layout o template (EditorTemplate o DisplayTemplate) no se encuentra localmente en la carpeta del caso de uso, este busca luego en las vistas del sub-módulo y luego en las vistas del módulo.

Conclusión

Dado que ni el ControllerFactory del framework de MVC permite tener controladores con el mismo nombre ni que el esquema de carpetas que por defecto que utiliza RazorViewEngine es suficiente para proyectos realmente grandes, creo que todo proyecto necesita contemplar la conveniencia de, antes de comenzar a desarrollar sus casos de uso, estudiar esta o alguna otra alternativa.

Yo recomiendo esta solución fuertemente ya que viene dándonos excelentes resultados día tras día y nos ha vuelto la vida increíblemente más sencilla.

[Video] Serie sobre excepciones–Malas Prácticas

Lucas Ontivero — Fri, 16 Dec 2011 22:50:33 GMT

Les dejo la segunda entrega de la serie que estoy desarrollando para el equipo de desarrollo en el cual trabajo.

Saludos

[Video] Serie sobre excepciones–Exceptions vs ErrorCodes

Lucas Ontivero — Fri, 16 Dec 2011 22:47:42 GMT

Les dejo el primero de una serie de videos sobre excepciones que estoy creando para el equipo de desarrollo al que pertenezco. Espero les guste.

Saludos

.Net Reflector y ILSpy, ¿podrían inferir mejor el código a partir del IL?

Lucas Ontivero — Sat, 10 Dec 2011 06:33:00 GMT

Muchas veces uno cree que el código que .Net Reflector muestra es fiel reflejo de lo que el desarrollador escribió, pero obviamente eso no puede ser cierto ya que esta herramienta toma el IL de un ensamblado y trata de mostrar su equivalente en los lenguajes que se le pida (C#, VB.NET, F# entre otros). Claro que muchas veces hacen tan buen trabajo que uno se olvida de eso.

Como a ILSpy le falta una vueltita de rosca en este aspecto, esto se hace más evidente ya que uno termina viendo código menos pulido como instrucciones GOTOs y otras yerbas en el propio código que uno escribió. Ahora bien, ¿que sucede cuando uno escribe 2 métodos con distintas instrucciones de un lenguaje pero equivalentes en funcionamiento? ¿Pueden estas herramientas hacer un buen trabajo?

Para responder a esta pregunta escribí tres métodos que hacen exactamente lo mismo: imprimen 100 líneas en la consola con los números del 0 al 99:

Quería ver si .Net Reflector y ILSpy podían ver la diferencia y la respuesta es: NO, NO PUEDEN. La razón es obvia ya que los tres métodos generan exactamente el mismo código intermedio (IL):

Dado que los tres métodos son idénticos bit a bit, ninguna herramienta podría determinar si corresponden a una instrucción for, while o a un enredo de gotos. Tampoco podríamos inferir cual fue el lenguaje con que se escribieron estos métodos (aunque eso poco importa). No obstante, esta es la estructura típica de un bucle for y por lo eso es que tanto .Net Reflector como ILSpy, cuando se les pide que muestren el código C# equivalente, muestran el siguiente fragmento para los tres métodos:

Ahora bien, el código IL es idéntico cuando se lo compila en modo Release pero no así cuando se lo compila en modo Debug ya que en este último caso, entre cada instrucción del lenguaje (digamos C#) se coloca una instrucción nop para habilitarnos a poner puntos de interrupción en partes de nuestro código que no se traducen a IL (no son instrucciones ejecutables). Por ejemplo, gracias a estos nops es que podemos poner un breakpoint al inicio de un bloque en modo Debug pero no así en modo Release:

En modo Debug esto este breakpoint es válido mientras que en modo Release el depurador pone automáticamente el breakpoint en la primera línea ejecutable despues de la llave {.

Ahora bien, dado que cada compilador agrega distinto número de instrucciones nop (esto podría ser falso ya que no probé todos los compiladores, obvio!) a los ensamblados compilador en modo Debug, herramientas como .Net Reflector y ILSpy podrían determinar cual es el lenguaje (en realidad, cual es el compilador) con que se generó ese ensamblado y también saber que un mismo algoritmo originalmente se desarrolló a partir de distintos conjuntos de instrucciones. Veamos el IL de los tres métodos originales en Modo Debug:

Como se ve estos tres ahora son diferentes y son aún más diferentes si los compilamos en VB.Net por esto es que digo que sería posible que cuando un ensamblado ha sido compilado en modo debug, estas herramientas cuentan con más información para inferir el código original. Y ya sé que el mundo no es solo C# y VB.Net y que esto quizás no vale la pena, solo digo que si estas herramientas quieren mostrar el código equivalente al IL en algunos de estos lenguajes, y el ensamblado está compilado en modo debug (casi nunca lo está), entonces podrían usar esta info para mostrar el código más parecido al original.

Como crear un Profiler para .Net

Lucas Ontivero — Thu, 08 Dec 2011 06:17:00 GMT

Quiero mostrar cómo es posible modificar nuestros assemblies ya compilador (no no no, antes que los procese el JIT) para agregarles o quitarles código IL. En este caso, voy a ilustrar esto mediante la creación de un sencillísimo Profiler.

Trabajos previos

Este está inspirado en un artículo muy interesante, aunque algo viejo, de Gabriel Schenker sobre como crear un profiler con Mono.Cecil para aplicaciones Silverlight (parte 1 y parte 2 – nos debe la tercera parte). Me gustó bastante pero por desgracia no puso el código (y odio cuando hacen eso!), usa una versión vieja de Mono.Cecil y me pareció buena idea cambiar algunas partes del enfoque original.

Paso a Paso

Objetivo

Lo primero es tomar un ensamblado .net y modificarlo inyectándole algún código. Lo que queremos lograr es, dado un método cualquiera como el que se ve abajo en la Fig.1 insertarle dos llamadas a dos métodos estáticos como se ve en la Fig.2:

Fig.1 – Método original

Fig.2 – Método instrumentado

Como puede verse, las dos llamadas extras, una al inicio y otra al final del método original, son métodos estáticos que recolectan información del tiempo de ejecución mediante un Stopwatch. Aquí hay una diferencia con la versión de Gabriel Schenker en cuanto a que yo le paso la firma del método mientras que el toma esa información del StackFrame dentro del método WhenEnteringMethod. Esto es más rápido y reduce mucho el código (aunque mi objetivo no fue “mejorar” el código sino simplemente jugar un rato). Otra diferencia es en la forma de medir el tiempo.

Instrumentando

Lo primero que hacemos es tomar la ruta de un ensamblado, leerlo con AssemblyDefinition.ReadAssembly, y luego por cada método encontrado llamamos a InstrumentMethod. Por último guardamos el ensamblado en la misma ruta (lo sobreescribimos).

Si el método tiene código, esto es: no es abstracto, no es un método de una interface, no es un método parcial, etc. Le inyectamos nuestras llamadas:

Aquí es donde insertamos la primera llamada y le pasamos por parámetro el nombre completo de método.

Recolectando información

Entonces ahora todos nuestros métodos, lo primero que hacen es invocar al método WhenEnteringMethod que muestro abajo:

Esto básicamente determina cual es el método que se estaba ejecutando y desde el cual se realiza la llamada al método que se está ejecutando en este momento. El método Enter es el que incrementa el número de llamados e inicia el stopwatch. Por último, cuando se sale del método se ejecuta WhenLeavingMethod el cual detiene el stopwatch.

Esto genera un árbol de llamadas que podemos ver con nuestro depurador. Por ejemplo, el método EntryPoint (método ficticio que representa al llamador de mas alto nivel) realiza dos llamadas (Calls): la primera al constructor de la clase AClass (AClass.ctor()) una solo vez la cual no tarda nada (0.0 milisegundos) y luego una llamada al método PublicVoidFunction la cual tarda 400 milisegundos. Esta última a su vez invoca 50 veces al método MethodWithAFunctionParameter.

Verlo en acción

Para visualizarlo con mayor facilidad podemos bajar esto a un xml y verlo así:

Conclusión

Hacer un buen profiler no es algo sencillo en lo absoluto y existen miles de consideraciones a tener en cuenta, no obstante este ejemplo es útil para demostrar lo sencillo que es manipular los ensamblados mediante Mono.Cecil lo que nos abre un universo inmenso de posibilidades para realizar herramientas como profilers, herramientas de coverage, herramientas para implementar AOP, ect.

El código puede descargarse desde aquí

Expresiones Lambda para novatos

Lucas Ontivero — Sat, 26 Nov 2011 04:30:48 GMT

Algunos compañeros me pidieron que explicara las expresiones lambda en un video. Este es muy básico y usa un lenguaje inexacto para hacerlo lo más entendible posible para aquellos que no conocen con suficiente profundidad .Net.

[Patterns] UnitOfWork

Lucas Ontivero — Wed, 17 Aug 2011 05:13:21 GMT

Leyendo el artículo de Javier Torrecilla Patrón Unit of Work (UoW) o Unidad de Trabajo me acordé que en 2007 había escrito sobre este patrón y quiero rescatarlo aquí:

Este es uno de los patrones más útiles (desde mi punto de vista) con que me he encontrado en el libro "Patterns of Enterprise Application Architecture" (P of EAA) de Martin Fowler. Como dice Martin en su libro este patrón:

"Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems."

Este patrón se utiliza entonces para trabajar con un conjunto de objetos persistentes que deben tratarse como una "unidad" de trabajo, almacenándose en una base de datos de manera atómica. Este patrón es el encargado de hacer el seguimiento de 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 base de datos y todos los que han sido borrados y deben quitarse de la base de datos.

Mediante la implementación del patrón UnitOfWork, se logra una disminución de la cantidad de idas y vueltas hacia la base de datos ya que los cambios se realizan por lotes (o unidades de trabajo) redundando en incremento en el rendimiento del sistema porque muchas veces el cuello de botella de las aplicaciones se encuentra en la red de datos. Otro aspecto interesante es que posibilita el esquema de trabajo desconectado con bloqueos optimistas sobre la base de datos, es decir, no se mantienen bloqueados los registros por largos períodos de tiempo sino que se abre una conexión, se inicia una transacción, se hacen los cambios, se hace commit y se libera la conexión todo esto en muy pero muy poco tiempo.

De ser necesaria la incorporación de un control de concurrencia sobre los registros que serán afectados durante la transacción, de modo de mantener la consistencia de los datos, este patrón nos brinda el ámbito adecuado en donde implementarlo.

Veamos un caso concreto, el famoso ejemplo de la factura. Existe una factura que el usuario debe modificar, entonces traemos desde la base de datos la factura con sus ítems (de factura) cargados, luego, una vez que lo presentamos en pantalla, el usuario hace lo siguiente:

Agrega dos ítems más a la lista de ítems,
Modifica el importe y/o la cantidad de productos de uno de los ítems y finalmente,
Elimina algún que otro ítem.

En este caso, cuando deben persistirse los datos? apenas agrega, modifica o elimina un ítem? 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 sus ítems 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álisis exhaustivo 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 de una propiedad, esta notifique al UnitOfWork correspondiente para que la registre como dirty, etc.

Acá dejo una implementación sencillísima de UnitOfWork sin control de concurrencias y en colaboración con un DataMapper trivial (actualización: el artículo original tenía un proyecto adjunto el cual he perdido, por esta razón el DataMapper no está presente pero lo que originalmente hacía era retornar la sentencia sql necesaria para insertar, modificar y borrar los objetos en la base de datos).

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;
using ConsoleApplication7;

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))
                {
                    // 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();
                }
                transactionScope.Complete();
            }
        }

        private void ClearAll()
        {
            newObjects.Clear();
            dirtyObjects.Clear();
            removedObjects.Clear();
        }
    }
}

Por qué no me gustan las plantillas T4

Lucas Ontivero — Fri, 05 Aug 2011 04:53:00 GMT

A mi anterior entrada la titulé “Las plantillas T4 son basura” cosa que respondió más a mi estado de bronca contra éstas que a su verdadero valor como herramienta. Muchos me preguntaron sobre el por qué de tal calificación y la verdad es que ese por qué es demasiado largo de explicar pero voy a mostrar la punta del ovillo para que a quien le interese pueda descubrirlo por sí solo.

Veamos un par de ejemplo muy sencillos, el primero es crear un CVS partir de una array definido como sigue:

Lo que queremos obtener es lo siguiente:

T4	StringTemplate

Ambos dan por resultado exactamente la misma salida. Ahora, como no soy experto en ninguno de los dos, doy por seguro que existen mejores maneras de hacerlo tanto usando T4 como StringTemplate. Pero, si damos por válido el ejemplo, podemos ver claramente la diferencia en legibilidad y, aunque el ejemplo es muy pequeños, en mantenibilidad la diferencia también es evidente.

Pero veamos algo levemente más complejo, solo un poquito más complejo, generemos una tabla html para ver algunas diferencias. Aunque con StringTemplate lo haría así:

Voy a refactorizarla y compararla en la tabla de abajo.

T4	StringTemplate

Nuevamente aquí estoy seguro de que existen mejores maneras de hacerlo tanto con T4 como con StringTemplate pero bueno, que valga el ejemplo. así que veamos… (suspiro prolongado) por donde empezar….?. quizás deba aclarar que mientras que la plantilla de la derecha está completa, a la de la izquierda le quité varios renglones con directivas varias del tipo <@template> y <@output>.

Antes de comenzar pregunto: ¿soy yo, o en la plantilla del lado izquierdo hay mucho amarillito?

Bueno, ahora si, lo primero es que dado que en la plantilla de la izquierda tenemos código, este puede explotar con alguna exception. Por ejemplo, que sucede si data es NULL? Sí, tendremos una bonita exception y entonces quizás debamos depurar la plantilla. Sí, leíste bien: depurar una plantilla! por más ridículo que suene, es algo que probablemente debamos hacer. En cambio, con la plantilla de la derecha obtendremos simplemente una tabla html vacía, no muy útil pero válida al fin.

Otro punto es que cualquiera que haya usado T4 ha sufrido alguna vez la pérdida de alguna etiqueta de apertura o cierre y ha perdido la vista tratando de encontrar donde es que le falta abrir o cerrar un tag. Y es que en semejante sopa de tags cualquiera se pierde. Por eso es común ver comentarios en la plantilla al estilo: // cierra foreach ya que uno termina preguntándose ¿que es lo que está cerrando esta llave? Bueno, esa llave está cerrando un foreach!

En cuanto a la calidad de la salida solo puedo decir que con la plantilla de la derecha, sin ningún esfuerzo adicional, obtengo un html perfectamente tabulado mientras que con la de la derecha….uhmmm, bueno… requiere algún trabajito adicional que se resuelve agregando más código.

Tal vez algo que me agrada de StringTemplate es que nos mantiene protegidos de sus mecanismos internos, es decir, uno no está obligado, y de hecho no debería estarlo, a entender cómo es que funciona internamente. Pero T4 si nos obliga, solo basta ver los distintos tipos de bloques que existen para darse cuenta: ¿Standard feature block?, ¿Class feature block? Además deben ir en un orden específico o no compilan. Sí, esas son las tuberías saliéndose hacia afuera a las que me refiero, el creador debe estar consciente de a dónde va a ir a parar lo que pone en cada block según el tipo de bloque, debe entender o imaginar como es la clase que T4 genera por detrás. Por tal motivo, T4 es solo para programadores.

Corto acá pero antes debo aclarar que no basta solo con “ver” las diferencias sino con “entender” las diferencias, entender todo lo conceptual que hay por detrás de la elegancia de StringTemplate (o de la inelegancia de T4).

KeyPadawan “Resurrection” 0.2 Released

Lucas Ontivero — Sat, 25 Jun 2011 22:25:00 GMT

KeyPadawan es una herramienta muy simple que permite visualizar lo que se escribe, en la pantalla.

Tiene 3 modos de ejecución:

Normal: Muestra tanto las teclas como los atajos que se utilizan.
Shortcuts: Solo muestra los atajos.
Raw: Muestra todas la teclas tal y cual las recibe desde el sistema operativo.

El código está alojado en Github [https://github.com/lontivero/KeyPadawan.git].

Ya compilado pueden encontrarlo aquí.

Cualquier sugerencia es bienvenida.

¿Lo que huele mal es la inyección de dependencias?

Lucas Ontivero — Fri, 15 Apr 2011 19:09:32 GMT

En mi anterior entrada mostraba distintas alternativas que podíamos utilizar para volver al siguiente fragmento de código fácilmente testeable. Obviamente existe una infinidad de alternativas que no he abordado como los frameworks de aislamiento, los servidores de smtp que no envían los mails y muchas más.

La idea aquí es mostrar el por qué este código no es un duro de testear. Obviamente es porque tiene una dependencia con la clase SmtpClient la cual se comunica mediante un socket con el ambiente externo.

Entonces, el problema radica en la sentencia:

Ahora bien, en algunos lenguajes como por ejemplo, Ruby. El mismo código es fácilmente testeable ya que las clases e incluso las instancias están abiertas para la modificación en tiempo de ejecución. Entonces en Ruby podemos sobre escribir el método “new” de manera que nos devuelva un tipo diferente al que le pedimos. ¿Podemos en C# hacer lo mismo? Ummm…. la respuesta correcta es no, pero podemos acercarnos bastante. Fijate si notas la diferencia entre el siguiente código y el primero:

¿La encontraste? Bien! Este código ahora si es testeable. De la siguiente manera:

A simple vista se parece mucho a una sobrecarga del operador “new”, también podría compararse con un contenedor de inversión de control o con una factoría. No es mi intención discutir ese tema sino mostrar como las características nuevas de c# 4 sobre el mundo dinámico nos puede ayudar a pensar en otros tipos de soluciones.

Les dejo todo el código (es solo una prueba de concepto):

using System;

using System.Collections.Generic;

using System.Net.Mail;

namespace CSharpDi

    public class Program

        public static void Main()

            typeof(SmtpClient).RegisterBuilder(p =>

new

                    Send = new Action<string, string, string, string>(

                    (from, to, subject, body) => { })

);

            var tm = new TranferManager();

            tm.Tranfer();

    public class TranferManager

        public void Tranfer()

            // Perform the required actions

            var smtpClient = New. SmtpClient();

            smtpClient.Send("info@bank.com", "from.Email", "Tranfer", "?");

    public static class New

        public static dynamic SmtpClient(params object[] parameters)

            return typeof(SmtpClient).New(parameters);

    public static class CreationExtensions

        private static Dictionary<Type, Func<object, dynamic>> builders =

            new Dictionary<Type, Func<object, dynamic>>();

        public static dynamic New(this Type type, params object[] parameters)

            if(builders.ContainsKey(type))

                return builders[type](parameters);

            return Activator.CreateInstance(type, parameters);

        public static void RegisterBuilder(this Type type, Func<object, dynamic> builder)

            builders.Add(type, builder);

¿Como vuelvo testeable mi código? Algo huele mal.

Lucas Ontivero — Fri, 15 Apr 2011 12:07:00 GMT

Veamos el siguiente código:

Lo que buscamos crear al menos una prueba unitaria para este. ¿Cómo lo hacemos?. Bueno, antes quiero plantear algunos supuestos:

Si bien parece un TransactionScript, hagamos de cuenta que no lo es. El hecho de tener solo un método y ningún campo, propiedad o evento es solo para hacer de este un ejemplo ultra sencillo. Por lo tanto pensemos que sí tiene campos, propiedades y varios métodos.
Si bien usamos un System.Net.Mail.SmtpClient, la idea es no limitarse solo a esta clase sino que puede ser cualquier otra (en este caso una clase de la BCL). Quizás no tenemos el código para modificarlo (como en este caso) o quizás sí lo tenemos pero modificarlo no es buena idea.
En principio solo queremos verificar que la transferencia se realiza y NO que el mail se envía correctamente.

Las opciones que analizaremos aquí son:

Inyección de dependencias (DI)
Sub clasificación
Decoración

Inyección de dependencias

Usar un Gateway es uno de los caminos más habituales que podemos encontrar para “volver testeable nuestro código”. Hacer esto con el único objetivo de testear el código para mí no solo que no vale la pena sino que es incorrecto. Es una sobre ingeniería, a pequeña escala en este caso, y un despropósito puesto que difícilmente tendremos en el futuro otro tipo de cliente de mail. El único cliente de mail extra existe solo con motivo de testing. Y además tenemos 2 constructores, una interface y una clase extra, etc, etc… horrible. ¡Si tan solo el método Send del SmtpClient fuese virtual!

Si no quisiéramos pagar ese costo, ahorrarnos la interface y la clase extra pero seguir utilizando la DI como mecanismo, lo que podríamos hacer es darnos una vuelta por el mundo dinámico. Básicamente, cualquier tipo que responda a “Send(string, string, string, string)” nos va a servir.

Las dos principales objeciones a esta alternativa vienen de parte de aquellos a quienes les disgustan (¿o asustan?) las implicaciones del chequeo de tipos en tiempo de ejecución como de aquellos a quienes les disgusta el inyectar este tipo de dependencias. Por lo demás, esto facilita bastante la creación de las pruebas. Abajo hay dos pruebas que usan tipos anónimos para realizar dos tipos de pruebas distintas.

Una solución intermedia entre inyectar tipos estáticos y dinámicos es inyectar acciones. Es decir, inyectar la pieza de código que queremos que se ejecute para enviar los mails como vemos abajo. Esto también facilita enormemente la creación de pruebas y si bien es aceptable, tiene, además del mismo mal olor de todas las alternativas que requieren inyectar dependencias, el problema de ser poco intuitiva. Veamos un ejemplo:

Conclusión parcial: la inyección de dependencias, en cualquiera de sus formas, nos puede ayudar a crear código más testeable aunque requiere de cierto código extra y ciertos patrones que no siempre redundan en mejor código. Por esta razón, la DI, en casos similares a los de los ejemplos que he presentado, no es una buena alternativa.

Sub clasificación

Uno podría argumentar que quizás nuestro método Tranfer necesita una pequeña refactorización la cual nos podría ayudar a mejorar el código y de pasada, hacerlo más testeable… veamos:

Ahora podemos crear versiones testeables de esta clase, ya sea a mano o utilizando algún framework de aislamiento.

Esto parece algo más limpio ¿verdad? No necesitamos extrañas interfaces, constructores, tipos dinámicos ni nada de lo que vimos con anterioridad. Una objeción: ¿qué sucede si la clase necesita ser sealed? Este punto de extensión ha sido creado nuevamente con el único propósito de posibilitar las pruebas porque de lo contrario, el método no sería protected virtual sino simplemente private. Ok, pero es una alternativa válida y nos sirve.

Decoración

Quizás la responsabilidad de enviar las notificaciones no sea algo propio de nuestra clase TranferManager y por lo tanto podríamos sacar esa responsabilidad a otra clase usando el patrón decorador (o podríamos usar un wrapper también). Veamos:

Ahora podemos testear TranferManager sin dificultades. El problema que se nos presenta ahora es que tal vez lo que necesitamos testear ahora sea la nueva clase TranferManagerWithNotification.

Esta entrada se ha vuelto muy extensa así que la continuaré más adelante…

Compiler as a Service – Parte 2

Lucas Ontivero — Tue, 22 Feb 2011 18:34:46 GMT

Si el compilador de C# pudiera utilizarse como cualquier assembly, podríamos generar código y compilarlo en tiempo de ejecución. Con esto, muchas de las cosas que hoy hacemos mediante CodeDom o Expression trees, las podríamos hacer simplemente concatenando strings (hay maneras mejores).

Por ejemplo, imaginemos un framework para crear clases Mock al que llamaremos RinhaMock. Aplicaremos este framework en el siguiente test unitario:

   1: [TestClass]

   2: public class Tests

   3: {

   4:     public void It_should_send_messages_with_values()

   5:     {

   6:         var sentMessage = string.Empty;

7:

   8:         dynamic sender = RinhaMock.Stub<IMessageSender>();

   9:         sender.When_Send_String = new Action<string>(s => sentMessage = s);

10:

  11:         var transacionManager = new TransactionManager(sender);

  12:         transacionManager.Deposit(amount: 50m, accountNo: "0087623481743", concept: "Pago cuota");

13:

  14:         Assert.AreEqual("50;0087623481743;Pago cuota", sentMessage);

  15:     }

  16: }

La idea es crear dinámicamente un tipo que implemente la interface IMessageSender y cuyo comportamiento pueda ser especificado fácilmente. Para que el ejemplo sea bien sencillo, vamos a tener una interface IMessageSender con solo un método y una clase TransactionManager igualmente simple:

   1: public interface IMessageSender

   2: {

   3:     void Send(string message);

   4: }

5:

   6: public class TransactionManager

   7: {

   8:     private IMessageSender _messageSender;

9:

  10:     public TransactionManager(IMessageSender messageSender)

  11:     {

  12:         this._messageSender = messageSender;

  13:     }

14:

  15:     internal void Deposit(decimal amount, string accountNo, string concept)

  16:     {

  17:         // Do the deposit here

  18:         var message = string.Format("{0};{1};{2}", amount, accountNo,concept);

  19:         _messageSender.Send(message);

  20:     }

  21: }

Ahora, la clase stub podría ser escrita por nuestras propias manos, como abajo:

   1: public class Stub__IMessageSender : CSharp5.IMessageSender

   2: {

   3:     public Action<System.String> When_Send_String { get; set; }

   4:     public void Send ( System.String message )

   5:     {

   6:         When_Send_String(message);

   7:     }

   8: }

O bien se podría creada a partir de la metadata de la interface IMessageSender y compilada en tiempo de ejecución. Esta última opción, que hoy tenemos con CodeDom, podría ser mucho más rápida y sencilla si el compilador de C# estuviera disponible como un assembly.

El código necesario para crear el código de la clase stub es el siguiente:

   1: public class RinhaMock

   2: {

   3:     public static T Stub<T>() where T : class

   4:     {

   5:         var typeOfT = typeof(T);

   6:         string stubName = "Stub__" + typeOfT.Name;

   7:         var sb = new StringBuilder();

8:

   9:         var methods = typeOfT

  10:             .GetMethods(BindingFlags.Instance | BindingFlags.Public | BindingFlags.InvokeMethod)

  11:             .Where(m => (m.IsVirtual || m.IsAbstract) && !m.IsSpecialName && !m.IsFinal);

  12:         methods.ForEach(m => sb.AppendLine(GetConfigPropertyCode(m)));

  13:         methods.ForEach(m => sb.AppendLine(GetMethodCode(m)));

14:

  15:         var scripRunner = new ScriptRunner(typeOfT);

  16:         var results = new Dictionary<string, object>();

  17:         scripRunner.AddObject<Dictionary<string, object>>("results", results);

  18:         scripRunner.AddUsing("CSharp5");

  19:         scripRunner.AddTypeCode(string.Format("public class {0} : {1} {{ {2} }}", stubName, typeOfT.FullName, sb.ToString()));

  20:         scripRunner.AddCode("results[\"stub\"] = new " + stubName + "();");

  21:         scripRunner.Run();

22:

  23:         return (T)results["stub"];

  24:     }

25:

  26:     private static string GetMethodCode(MethodInfo method)

  27:     {

  28:         var isProcedure = method.ReturnType == typeof(void);

  29:         var parameters = method.GetParameters();

30:

  31:         return string.Format("public {6} {0} {1} ( {2} ) {{ {3} When_{1}{5}({4}); }}",

  32:             isProcedure ? "void" : method.ReturnType.FullName,

  33:             method.Name,

  34:             parameters.Select(p => string.Concat(p.ParameterType.FullName, " ", p.Name)).ToStringList(),

  35:             isProcedure ? string.Empty : "return",

  36:             parameters.Select(p => p.Name).ToStringList(),

  37:             parameters.Any()

  38:                 ? "_" + parameters.Select(p => p.ParameterType.Name.Replace("[]", "Array")).ToStringList("_")

  39:                 : string.Empty,

  40:             method.DeclaringType.IsInterface ? "" : "override"

  41:             );

  42:     }

43:

  44:     private static string GetConfigPropertyCode(MethodInfo method)

  45:     {

  46:         var isProcedure = method.ReturnType == typeof(void);

  47:         var parameters = method.GetParameters();

48:

  49:         var methodReturnedType = isProcedure ? "void" : method.ReturnType.FullName;

  50:         var parametersType = parameters.Select(p => p.ParameterType);

  51:         var returnedSign = isProcedure ? "Action<{0}>" :

  52:             string.Format("Func<{0}{1}>", "{0}", (parametersType.Any() ? "," : "") + methodReturnedType);

  53:         var parametersForSign = parametersType.Select(t => t.Name.Replace("[]", "Array")).ToStringList("_");

54:

  55:         return string.Format("public {0} When_{1}{2} {{ get; set; }}",

  56:             isProcedure && !parameters.Any()

  57:                 ? "Action"

  58:                 : string.Format(returnedSign, parametersType.Select(t => t.FullName).ToStringList()),

  59:             method.Name,

  60:             parametersType.Any() ? "_" + parametersForSign : string.Empty);

  61:     }

  62: }

63:

  64: static class StringListExtensions

  65: {

  66:     public static string ToStringList(this IEnumerable<string> enumerable, string separator = ", ")

  67:     {

  68:         if (!enumerable.Any())

  69:             return string.Empty;

70:

  71:         return enumerable.Aggregate((s1, s2) => string.Concat(s1, separator, s2));

  72:     }

  73: }

74:

  75: static class IEnumerableExtensions

  76: {

  77:     public static void ForEach<T>(this IEnumerable<T> enumerable, Action<T> action)

  78:     {

  79:         foreach (var t in enumerable) action(t);

  80:     }

  81: }

Como se puede ver, esta podría ser una alternativa viable a todos esos frameworks para la creación de clases proxies como Castle.DynamicProxy (usado por RhinoMocks).

Compiler as a Service – Parte 1

Lucas Ontivero — Tue, 22 Feb 2011 15:31:55 GMT

Pensaba acerca de las cosas que podríamos hacer si el compilador de C# fuese un assembly reutilizable (Compilar as a service). Lo primero, y menos original, que se me ocurrió es que podríamos tener algo como JSON pero para C# en lugar de Java Script.

   1: class Program

   2: {

   3:     static void Main(string[] args)

   4:     {

   5:         const string data = @"results[""professional""] =

   6:         new

   7:         {

   8:             FirstName = ""Juan Pablo"",

   9:             LastName = ""Ibañez"",

  10:             Certifications = new[]

  11:             {

  12:                 new { Provider=""MSFT"", ExamCode = ""70-536"", Title = ""Application Development Foundation"" },

  13:                 new { Provider=""MSFT"", ExamCode = ""70-505"", Title = ""Application Development Foundation"" },

  14:                 new { Provider=""MSFT"", ExamCode = ""70-563"", Title = ""Application Development Foundation"" }

  15:             },

16:

  17:             SayHi = new System.Action(()=> System.Console.WriteLine(""Hi""))

  18:         };";

19:

  20:         dynamic professional = CSharpEvaluator.Evaluate(data)["professional"];

21:

  22:         Console.WriteLine("First Name: {0}", professional.FirstName);

  23:         Console.WriteLine("Last Name : {0}", professional.LastName);

  24:         foreach (var certification in professional.Certifications)

  25:         {

  26:             Console.WriteLine("\tCertification: {0}", certification.Title);

  27:         }

  28:         professional.SayHi();

  29:     }

  30: }

Esto abriría realmente muchas posibilidades. Una de las que me atrae más es el sustituir los XMLs. Quizás para guardarlos en una base de datos como entidades completas y hacerlas viajar por la red.

Sobre los frameworks de BDD

Lucas Ontivero — Thu, 02 Sep 2010 04:30:00 GMT

BDD como idea original me parece correctísima. No obstante, la mayoría de los frameworks para llevar sus conceptos a cabo en C# me parecen ridículos. Veamos una misma prueba de ejemplo escrita de dos maneras:

Alternativa 1:

[Subject(typeof(Account), "Funds tranfer")]
public class When_transferring_between_two_accounts
{
    static Account fromAccount;
    static Account toAccount;
    Establish context = () =>
    {
        fromAccount = new Account { Balance = 1m };
        toAccount = new Account { Balance = 1m };
    };
    Because of = () => fromAccount.Transfer(1m, toAccount);
    It should_debit_the_from_account_by_the_amount_transferrend = () =>
        fromAccount.Balance.ShouldEqual(0m);
    It should_credit_the_to_account_by_the_amount_transferrend = () =>
        toAccount.Balance.ShouldEqual(2m);
}

Alternativa 2:

[TestFixture]
public class TransferringSpces
{
    [Test]
    public void It_should_debit_from_source_account_and_credit_to_target_account()
    {
        var fromAccount = new Account(balance: 1m);
        var toAccount = new Account(balance: 1m);
        fromAccount.Transfer(1m, toAccount);
        Assert.That(toAccount.Balance, Is.EqualTo(2m));
        Assert.That(fromAccount.Balance, Is.EqualTo(0m));
    }
}

¿Es la primera prueba más clara que la segunda?, ¿Ayudan todos esos delegados (Establish, Because, It) a comunicar mejor el comportamiento del método que hace la transferencia?