Omar del Valle Rodríguez

[Web Socket] Un evento en el tintero (introducción)

A finales del año pasado, tenía la idea de dar un evento sobre Web Socket, por motivos que no vienen al caso el evento no se dará, así que he decidido crear una serie de post con lo que pretendía ser “Web socket por dentro…”

Sin Frameworks…

Hoy en día existe un framework casi para cualquier cosa, frameworks para Javascript, frameworks para IoC, frameworks para MVC, MVVM, bases de datos y así, podríamos pasarnos buen rato enumerando. Como no podría ser de otra forma, también hay frameworks para WebSockets.

Un framework es un pedazo de código que nos hace más fácil determinado trabajo y que puede ser reutilizado en uno o varios proyectos. Su uso está más que justificado, no queremos reinventar la rueda, por lo que todo aquello que nos ahorre trabajo, tendrá todas las papeletas para ser incluido en nuestro proyecto.

De igual forma que un framework ayuda, encierra a la vez dos grandes peligros si lo usamos sin conocer cómo funciona internamente.

El primero de ellos es incluirlo directamente en nuestro proyecto por no saber hacer las cosas de otro modo. Así  por ejemplo, pudiéramos terminar creando una referencia a jQuery cuando solo necesitamos obtener un elemento del DOM por su Id, o lo que es lo mismo, que estemos intentando matar un mosquito con una sofisticada herramienta de artillería.

Tenemos que tener en cuenta que un framework está hecho para cubrir y resolver el mayor número de problemáticas posibles sobre algo en específico, por lo que puede ser exagerado incluirlo cuando necesitamos tan solo el 0,1% de su funcionalidad.

El otro gran peligro y que casi siempre olvidamos es que los frameworks están hechos por programadores, persona o grupo de personas con muuuuuuchos derechos a equivocarse. Si en un momento dado nos encontramos con un error, difícilmente vamos a poder colaborar resolviéndolo e incluso, ni siquiera sabremos explicar qué ha pasado o qué puede estar produciendo el error.

Es por eso que antes de entrar en el mundo de los frameworks con web sockets, esta serie de artículos intentará dar a conocer cómo funcionan por dentro.

Para esto me he propuesto el siguiente índice de artículos:

1. Introducción ¿Por qué no usaremos un framework? (este artículo)
2. Web Socket. El server.
3. Web Socket. El cliente.
4. Primer ejemplo: La pizarra de @chalalo sin SignalR
5. Segundo ejemplo: Presentaciones paralelas con Reveal.js.
6. Tercer ejemplo: Presentaciones paralelas con Reveal.js y Kinect

Hasta el próximo..

Mockeando Window.location

Estoy en un proyecto donde tengo que interactuar con servicios RestFul desde javascript. El problema que tengo es que estos servicios están aún en desarrollo por lo que cuando me toca trabajar con ellos puede que estén o no disponibles.

Para evitar detener mi trabajo cuando los servicios no están disponibles he decidido que los test trabajen con mocks. Hace unos días me tocó hacer un test para chequear un método que internamente hacía uso de window.location.

Hay muchas soluciones disponibles para testear nuestro método, veamos una de ella:

Este sería nuestro objeto en javascript el cual contiene un método llamado NavigateTo y al que le pasamos dos parámetros para formar una url.

Probar este método es muy fácil: (usaremos qunit por su cómoda integración con ReSharper)

Nuestro test pasa sin problemas.

En el momento en que necesitemos que nuestro objeto trabaje con el objeto real, solo tenemos que pasar el window en el constructor.

Otra solución y mi preferida, es encapsular la llamada a window.location.href en una función que podamos usar desde cualquier parte en nuestro proyecto. Luego solo tendríamos que mockear la función y testear que todo esté correcto.

Aquí ya no estamos falseando el objeto window sino que encapsulamos su utilización dentro de un objeto Browser que contiene un método llamado  Navigate.

Para testear el ejemplo anterior, vamos a usar Sinon y su pluging para qunit. Como estamos trabajando con ReSharper para las pruebas, debemos indicar la referencia a estos frameworks en nuestro js de pruebas.

Ya con esto podemos crearnos nuestro test:

y el resultado…

Lo que me gusta de este método respecto al anterior es que no tenemos necesidad de falsear un objeto nativo del DOM. Por el contrario, lo que hacemos es mokear un objeto nuestro y testear su funcionalidad.

Microsoft Hosted Network Virtual Adapter

…o lo que es lo mismo, un router virtual WIFI en mi ordenador. :) …y aquí es donde quizás los de IT digan: ¿Y ahora es que te enteras…?

Resulta que el próximo martes toca realizar una presentación de una aplicación Web y para la cual necesitamos que estén conectados a una misma red: dos ordenadores, un iPad y un Tablet con Windows 8.

Posibles soluciones y problemas:

1- WIFI
Solución: Espero a que el lugar de la presentación tenga WIFI, y además el salón tenga cobertura.

Problema: Pierdes tiempo configurando conexiones en los dispositivos, problemas de coberturas, la primera impresión que se deja es un poco de “estamos perdiendo tiempo”

2- Router WIFI
Solución: Me llevo un Router WIFI previamente configurado y conecto a todo el mundo: Imaginen llegar, sacar un iPad, un tablet de W8, dos ordenadores, una kinect y un router con antenita al estilo “Star Wars light sabers” :)

Problemas: Necesito un router físico y más conectores de alimentación

3- Tengo un Nokia Lumia 800
Solución: Puedo activar “Compartir conexión” lo cual activa en mi teléfono un host WIFI al cual puedo conectar a todo el mundo.

Problemas: Pobre Nokia Lumia… ¿Cuanto dudará la batería? :)

4- Si el teléfono crea un Host WIFI virtual, ¿no podré hacer lo mismo en mi ordenador? Googleando…

Solución: Mi querido amigo netsh

Pues bien, como este trabajo no es de desarrollo sino de IT, en vez de cargar Visual Studio 2012, cargamos la consola de comandos “cmd” y, recuerden que tienen que hacerlo con permisos de administración…

Ejecutamos un primer comando:
netsh wlan set hostednetwork mode=allow ssid=odelvalle key=MyPassword

wlan: Wireless Lan (vamos a trabajar sobre la conexión WIFI)
set hostednetwork: (vamos a trabajar con las propiedades del hostednetwork).

El hostedNetwork es una funcionalidad soportada en W7, W8 y los 2008R2 en adelante…  Su principal objetivo es (para IT) virtualizar un adaptador wireless (para desarrolladores) un router WIFI de toda la vida.

El resto de los comandos indican si vamos a permitir conexión (mode), el nombre que le pondremos a nuestra WIFI (ssid) y la contraseña (key).

Todo lo anterior configura y deja listo nuestro hostednetwork, pero necesitamos echarle a funcionar y, para eso ejecutamos un segundo comando:

netsh wlan start hostednetwork

Este segundo comando inicia el  hostednetwork y deja nuestra vista de adaptadores de red de la siguiente forma:

y mi Nokia Lumia….

Espero q a alguien le sirva…. Salu2

RESTFul en Windows 8

Para las aplicaciones que he realizado para WP7 tenía un helper que me ayudaba a consultar servicios RESTful, pero la verdad, con todo el tema de async, await y Task, es motivo suficiente como para plantearse rescribir cualquier código asíncrono escrito con anterioridad.

Para nuestro helper vamos a necesitar fundamentalmente 2 clases, aunque implementaremos una tercera clase para el tema de serialización.

A todas las clases les vamos a definir una interfaz, las ventajas ya las conocemos: no atamos las clases que usen nuestro helper a nuestra implementación y además, podremos inyectar el helper usando IoC si trabajamos con MVVM.

Empecemos justo por la clase que se encargará de serializar y de-serializar:

public interface IJsonResolver
{
    Task<byte[]> Serialize(object graph);
    Task<T> Deserialize<T>(Stream respnseResult) where T : class;
}

Nuestra interfaz tiene dos métodos que nos permitan serializar y de-serializar nuestros objetos. Estos métodos retornan un Task, por lo que podremos usar su condición asíncrona durante la implementación.

En mi caso, voy a usar Json.net para implementar esta interfaz, pero ustedes pueden elegir su propia implementación.

public class JsonResolver : IJsonResolver
{
    private async Task<string> SerializeToString(object graph)
    {
        return await JsonConvert.SerializeObjectAsync(graph, Formatting.Indented, new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore });
    }

    public async Task<byte[]> Serialize(object graph)
    {
        if (graph is string) return Encoding.UTF8.GetBytes(graph as string);

        var json = await SerializeToString(graph);
        return Encoding.UTF8.GetBytes(json);
    }

    public async Task<T> Deserialize<T>(Stream respnseResult) where T : class
    {
        T result;

        using (var sr = new StreamReader(respnseResult))
        {
            var r = await sr.ReadToEndAsync();
            result = await JsonConvert.DeserializeObjectAsync<T>(r, new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore });
        }

        return result;
    }
}

Ya tenemos nuestra implementación, vamos a lo que de verdad nos interesa.

La utilización de un servicio web, ya sea Rest, Xml o cualquier otro formato, está compuesto principalmente por dos elementos:

1. El Request: Este elemento podría contener la URL a la cual vamos a realizar la petición, qué tipo de petición vamos a realizar (si es GET, POST, u otra), el ContentType, los parámetros, etc…
2. Un cliente que realiza la petición usando todas las opciones definidas en el Request.

Siguiendo esta lógica, mi Helper tendrá dos clases más: un RestRequest y un RestClient.

Vamos a definir la interfaz para el RestRequest.

public interface IRestRequest
{
    Uri Url { get; }
    string PostParameter { get; }
    Method Method { get; }
    string Accept { get; }
    string ContentType { get; }

    /// <summary>
    /// Add Parameter to URL. Value is not encode. If Method is POST, parameter is pass in body, if Method is Get, parameter is pass in URL.
    /// </summary>
    /// <param name="name">Parameter name</param>
    /// <param name="value">Parameter value</param>
    void AddParameter(string name, string value);

    /// <summary>
    /// Add Parameter to URL. This method encode parameter value by default
    /// </summary>
    /// <param name="name">Parameter name</param>
    /// <param name="value">Parameter value</param>
    /// <param name="pType"> </param>
    void AddParameter(string name, string value, ParameterType pType);

    /// <summary>
    /// Add Parameter to URL. This method encode parameter value by default
    /// </summary>
    /// <param name="name">Parameter name</param>
    /// <param name="value">Parameter value</param>
    /// <param name="encode"> </param>
    void AddParameter(string name, string value, bool encode);

    /// <summary>
    /// Add Parameter to URL. 
    /// </summary>
    /// <param name="name">Parameter name</param>
    /// <param name="value">Parameter value</param>
    /// <param name="encode">if true, encode parameter value</param>
    /// <param name="pType"></param>
    void AddParameter(string name, string value, bool encode, ParameterType pType);
}

En esta interfaz tenemos varios elementos que nos ayudan a configurar nuestro Request antes de realizar la petición.

El método AddPArameter cuenta con varias sobrecargas ya que vamos a tener varias posibilidades de pasar parámetros. Vamos a verlo uno por uno empezando por el más complejo (el último):

1. Este método recibe un nombre, un valor, permite indicar si el valor del parámetro debe ser “encodeado” o no y el tipo de parámetro que estamos utilizando.
   1. El “encodear” el valor de un parámetro es usado fundamentalmente cuando pasamos el valor por GET, ya que hay caracteres que no son válidos como parte de la URL
   2. ParamType es un enumerado que me indica el tipo de parámetro que vamos a pasar a nuestro objeto: QueryString (GET?nombre=valor), Post (se pasa en el body) y UrlSegment que es utilizado cuando el parámetro es parte de la URL. Ej. http://odelvalle.com/{parametro}/Rest
2. Un segundo método en que no es necesario pasar el tipo de parámetro. En este caso el tipo es determinado según el método usado para el Request, si es GET se pasa por QueryString, si es Post, se pasa en el body.
3. Otro método que nos permite indicar solo el nombre, el valor y el tipo de parámetro. Todos los parámetros pasados mediante este método, el value es “encodeado”.
4. Finalmente, tenemos un método que nos vale para pasar solo el nombre y el valor. Los parámetros que se pasen usando esta sobrecarga no se van a “encodear” y el tipo de parámetro es determinado por el tipo de Request (GET o POST)

Las propiedades definidas en la interfaz nos brindan el resto de la información necesaria para formar nuestro Request. Vamos a ver la implementación

public enum ParameterType
{
    QueryString,
    Post,
    UrlSegment
}

public enum Method
{
    GET,
    POST,
    PUT,
    DELETE,
    HEAD,
    OPTIONS,
    PATCH
}

public enum ContentType { Json, UrlEncoded }

public class RestRequest : IRestRequest
{
    struct Parameter
    {
        public string Name { get; set; }
        public string Value { get; set; }

        public ParameterType ParameterType { get; set; }
    }

    private readonly IList<Parameter> _parameters;

    private readonly string _url;
        
    public RestRequest(string url, Method method)
    {
        _parameters = new List<Parameter>();
        _url = url;

        Method = method;
    }

    public Uri Url
    {
        get
        {
            var buildUri = new UriBuilder(_url) { Query = BuildQueryString(ParameterType.QueryString) };
            return buildUri.Uri;
        }
    }

    public string PostParameter { get { return BuildQueryString(ParameterType.Post); }}
    public Method Method { get; private set; }

    public string Accept { get { return "application/json"; }}
    public string ContentType { get { return "application/x-www-form-urlencoded"; } }

    public void AddParameter(string name, string value)
    {
        AddParameter(name, value, false);
    }

    public void AddParameter(string name, string value, ParameterType pType)
    {
        AddParameter(name, value, true, pType);
    }

    public void AddParameter(string name, string value, bool encode)
    {
        AddParameter(name, value, encode, (Method == Method.GET) ? ParameterType.QueryString : ParameterType.Post );
    }

    public void AddParameter(string name, string value, bool encode, ParameterType pType)
    {
        var val = encode ? Uri.EscapeDataString(value) : value;

        if (pType == ParameterType.UrlSegment) _url.Replace(string.Format("{{0}}", name), val);
        else _parameters.Add(new Parameter { Name = name, Value = val, ParameterType = pType});
    }

    private string BuildQueryString(ParameterType pType)
    {
        var plist = _parameters.Where(p=> p.ParameterType == pType).Select(p => string.Concat(p.Name, "=", p.Value));
        return String.Join("&", plist.ToArray());
    }
}

Al constructor de la clase RestRequest le vamos a pasar la URL a la cual queremos realizar la petición y el método a utilizar.

Ya con esto tenemos nuestro RestRequest, vamos a ver el cliente que realizará la petición. Empezamos viendo la interfaz:

public interface IRestClient
{
    Task<T> Execute<T>(IRestRequest request) where T : class;
}

.. y eso es todo. No necesitamos nada más ya que estamos definiendo un cliente que recibirá un objeto RestRequest y hará una petición. Veamos la implementación.

public class RestClient : IRestClient
{
    private readonly IJsonResolver _resolver;

    public RestClient(IJsonResolver resolver)
    {
        _resolver = resolver;
    }

    public async Task<T> Execute<T>(IRestRequest request) where T : class 
    {
        var wr = WebRequest.CreateHttp(request.Url);

        wr.Method = request.Method.ToString();
        wr.Accept = request.Accept;
        wr.ContentType = request.ContentType;

        if (!string.IsNullOrEmpty(request.PostParameter))
        {
            return await ExecuteWithData<T>(wr, request);
        }

        var response = await wr.GetResponseAsync();
        return await _resolver.Deserialize<T>(response.GetResponseStream());
    }

    private async Task<T> ExecuteWithData<T>(WebRequest wr, IRestRequest request) where T : class
    {
        var body = await _resolver.Serialize(request.PostParameter);

        using (var stream = await wr.GetRequestStreamAsync())
        {
            await stream.WriteAsync(body, 0, body.Length);
        }

        var response = await wr.GetResponseAsync();
        return await _resolver.Deserialize<T>(response.GetResponseStream());
    }
}

Nuestro cliente recibe en el constructor el RestRequest que se desea realizar. Mediante el método Execute, el cliente se encarga de realizar la petición y si hay respuesta del servicio Rest, entonces nos retornará el objeto listo para usarse.

Para probar todo esto y ver lo simple que es de usar, me busqué alguna ejemplo Rest que ya existiera para Windows 8.  Aquí tenéis una: Metro client for Web API CRUD

En esta aplicación al final de la clase MainViewModel.cs tenemos el GET usando HttpClient y DataContractJsonSerializer.

using (var http = new HttpClient())
{
    var resp = await http.GetAsync(new Uri(ApiRoot));
    using (var stream = await resp.Content.ReadAsStreamAsync())
    {
        var djs = new DataContractJsonSerializer(typeof(List<Person>));
        People = new ObservableCollection<Person>((IEnumerable<Person>)djs.ReadObject(stream));
    }
}

Vamos a quitar ese código y vamos a usar el nuestro:

var request = new RestRequest(ApiRoot, Method.GET);
var restFul = new RestClient(new JsonResolver());

People = new ObservableCollection<Person>(await restFul.Execute<IEnumerable<Person>>(request));

… ¿probamos?

Aquí dejo la aplicación de ejemplo modificada y usando nuestro Helper.

PD: Aún no he probado todo el Helper, así que es posible que en un escenario específico pueda aparecer algún BUM

Carga de páginas en Chrome, rápido sí, pero ¿seguro?

Estoy haciendo una aplicación que usa Web Socket. Como navegador, por políticas del cliente, se está usando Chrome.

Resulta que en unas de mis pruebas, descubro algo que al menos a mi, me deja un “tin” preocupado respecto a Chrome.

Observen:

Lo que está pasando aquí es que yo abro Chrome, comienzo a escribir la URL y el navegador me propone la URL a usar. El problema es que yo aún no he confirmado que es esa, ni siquiera le he dicho a Chrome que navegue a esa URL, pero ya mi servidor de Web Socket ha detectado una conexión entrante.

¿Entonces?… Pues muy probablemente el listillo de Chrome navegue por detrás para dar la impresión posteriormente de que las páginas cargan más rápido… pero ¿Esto da un poco de miedo no? y más si yo sé que mi web socket en el cliente se inicializa y se ejecuta en el momento en que la página ha sido totalmente cargada, o sea, en el ready.

Probé con IE10 y no pasa. No he probado con más browsers.

Salu2

Repository Pattern para ApplicationData en Windows 8

Con la llegada de Windows 8 y sus aplicaciones para el Store, muchas veces nos toca lidiar con datos almacenados en local.

La idea de este post es implementar el patrón repositorio para independizar nuestras aplicaciones del trabajo con los distintos tipos de almacenamientos en local que existen en Windows 8.

Para profundizar en este patrón puedes echar un ojo a este enlace de Martin Fowler: http://martinfowler.com/eaaCatalog/repository.html

El objetivo

- Evitar código duplicado
- Mejor gestión de errores (código centralizado)
- Menos dependencia de nuestras reglas de negocio a la persistencia
- Posibilidad de centralizar políticas relacionadas con datos como el almacenamiento en caché o Lazy load.
- Posibilidad de “testear” la lógica de negocio de forma aislada a la persistencia

Empezamos creándonos una clase abstracta que nos permita de forma genérica trabajar con cualquier tipo de datos. La clase incluirá los métodos más generales para interactuar con el almacenamiento.

Constructores

Nuestra clase genérica incluye dos constructores, uno que por defecto usará el LocalFolder y otro que nos permitirá especificar el lugar de almacenamiento.

protected Repository(string fileName) : this(fileName, StorageType.Local)
{
}

protected Repository(string fileName, StorageType storageType)
{
   _fileName = fileName.EndsWith(".json") ? fileName : string.Format("{0}.json", fileName);

   // set the storage folder
   switch (storageType)
   {
      case StorageType.Local:
         _storageFolder = _appData.LocalFolder;

         break;
      case StorageType.Temporary:
         _storageFolder = _appData.TemporaryFolder;

         break;
      case StorageType.Roaming:
         _storageFolder = _appData.RoamingFolder;

         break;
      default: throw new Exception(String.Format("Unknown StorageType: {0}", storageType));
   }
}

El parámetro fileName nos sirve para especificar un nombre de archivo para nuestros datos. El archivo será identificado siempre por la extensión json y podemos decidir pasar el parámetro con o sin ella, en cualquier caso el constructor se encargará de realizar el chequeo necesario.

El parámetro storageType es un enumerado que incluye los distintos tipos de almacenamiento.

public enum StorageType
{
   Local,
   Temporary,
   Roaming
}

Dependiendo de este parámetro, el constructor inicializa  el StorageFolder a usar por nuestro repositorio.

Los métodos

/// <summary>
/// Delete a file asynchronously
/// </summary>
public async void DeleteAllAsync()
{
   var file = await GetFileIfExistsAsync(_fileName);
   if (file != null) await file.DeleteAsync();
}

Este método nos permite eliminar todos los datos almacenados. La operación se realiza de forma asíncrona y se resume a eliminar el archivo donde se encuentran almacenados nuestros datos.

El método GetFileIfExists nos retorna de forma asíncrona un StorageFile si el archivo existe, de lo contrario retorna nulo.

/// <summary>
/// At the moment the only way to check if a file exists to catch an exception... 
/// </summary>
/// <param name="fileName"></param>
/// <returns></returns>
private async Task<StorageFile> GetFileIfExistsAsync(string fileName)
{
   try
   {
      return await _storageFolder.GetFileAsync(fileName);
   }
   catch
   {
      return null;
   }
}

La única forma que tenemos de saber si un archivo existe es capturando el error. La razón que Microsoft nos da para no contar con un File.Exists en el API es que el estado del archivo puede cambiar entre que nosotros preguntamos si existe y realizamos alguna operación. Según Microsoft, si contáramos con un File.Exists, igualmente tendríamos que capturar posibles errores cuando trabajamos con el archivo.

/// <summary>
/// Persist data to StorageFolder
/// </summary>
public virtual void Flush()
{
   SaveAsync(Data.Value);
}

El método Flush usa Data.Value para indicar los datos a persistir. Esto no es más que el lugar en memoria donde está almacenado nuestro objeto.

protected Lazy<T> Data;

El uso de Lazy<T> nos permite acceder a StorageFolder en el momento en que se necesiten los datos  por primera vez.

Los datos de memoria se envían al StorageFolder que seleccionemos llamando a un método interno de nuestro repositorio que realiza la persistencia de forma asíncrona.

/// <summary>
/// Saves a serialized object to storage asynchronously
/// </summary>
/// <param name="data"></param>
protected async void SaveAsync(T data)
{
   if (data == null) return;

   var file = await _storageFolder.CreateFileAsync(_fileName, CollisionOption);
   await FileIO.WriteTextAsync(file, Serialize(data).Result);
}

El método interno SaveAsync crea nuestro archivo si este no existe, de lo contrario lo re-escribe.  Estamos usando ReplaceExisting como política de Colisión, de cualquier forma, esta  variable es protegida en nuestra clase base, así que puede ser cambiada por las clases que heredan.

protected CreationCollisionOption CollisionOption = CreationCollisionOption.ReplaceExisting;

De la misma manera que guardamos en el StorageFolder, también necesitamos leer. El siguiente método nos permite recuperar un objeto de forma asíncrona.

/// <summary>
/// Load a object from storage asynchronously
/// </summary>
/// <returns></returns>
protected async Task<T> LoadAsync()
{
   try
   {
      var file = await _storageFolder.GetFileAsync(_fileName);
      var data = await FileIO.ReadTextAsync(file);

      return await Deserialize(data);
   }
   catch (FileNotFoundException)
   {
      //file not existing is perfectly valid so simply return the default 
      return default(T);
   }
}

Tanto para leer, como para escribir datos en nuestro repositorio, se usan métodos que se encargan del trabajo de serialización del objeto.

Como cada cual tiene su propio mecanismo para serializar, estos métodos son declarados como abstractos dentro de nuestra clase base, de esta forma, podemos indicar en cada clase que herede, cual será la manera en que se serializarán los objetos, incluso, pudiéramos tener dentro de la misma aplicación, objetos que se persistan usando mecanismos de serialización totalmente distintos.

protected abstract Task<string> Serialize(T data);
protected abstract Task<T> Deserialize(string data);

He dejado para el final una propiedad que nos retorna nuestro objeto desde el StorageFolder o de memoria según sea el caso.

/// <summary>
/// Return T
/// </summary>
public virtual T All
{
   get { return Data.Value; }
}

Teniendo en cuenta que nuestro Repositorio puede valer para almacenar un simple objeto o una lista de objetos, tener una propiedad pública que nos retorne “todo” no es una muy buena práctica. De cualquier forma esto no viene a sustituir grandes almacenes de datos, ya que para eso tenemos bases de datos locales como SQLLite, sino que está pensado para pequeños datos. Es por esto que me tomo la libertad de incluir una “mala” práctica en mi código.

Nuestra clase base está lista, vamos a ver cómo usarla.

Para la implementación, voy a usar Newtonsoft.Json para la serialización de los objetos. Las clases a utilizar con los repositorios serán una simple y otra una lista, para poder ver las dos formas de utilizar nuestro repositorio.

public class Account
{
   [JsonProperty]
   public string Name { get; set; }
}

public class Family : List<Person>
{
   [JsonProperty]
   public IList<Account> Itenms { get; set; }
}

public class Person
{
   [JsonProperty]
   public Guid Id { get; set; }

   [JsonProperty]
   public string Name { get; set; }

   public bool IsTransient
   {
      get { return Id == Guid.Empty; }
   }
}

Nuestro repositorio siempre trabaja con un objeto, por lo que la única diferencia entre guardar un objeto simple o una lista, no es otra que usar uno o lo otro.

En el ejemplo crearemos un repositorio para Account y otro para Family que es una lista de Person.

Vamos a ver el repositorio de Family:

    public class RepositoryFamily : Repository<Family>, IRepositoryFamily
    {
        public RepositoryFamily(): base("Family")
        {
            CollisionOption = CreationCollisionOption.OpenIfExists;
            Data = new Lazy<Family>(() => LoadAsync().Result ?? new Family(), true);
        }

        public async Task<Person> Get(Guid id)
        {
            return await Task.Factory.StartNew(() => All.Single(p => p.Id == id));
        }

        public void Save(Person person)
        {
            if (person.IsTransient)
            {
                person.Id = IdentityGenerator.NewSequentialGuid();
                Data.Value.Add(person);

                return;
            }

            var idx = Data.Value.FindIndex(a => a.Id == person.Id);
            Data.Value[idx] = person;
        }

        protected override Task<string> Serialize(Family data)
        {
            return JsonConvert.SerializeObjectAsync(data);
        }

        protected override Task<Family> Deserialize(string data)
        {
            return JsonConvert.DeserializeObjectAsync<Family>(data);
        }
    }

Como se ve, implementamos los métodos abstractos del repositorio para serializar y ya solo nos queda ir implementando los métodos que necesitemos según el tipo de datos que estemos trabajando.

Para el ejemplo, tengo el método Save que adiciona una persona en la lista si no existe, o de lo contrario, lo actualiza.

Cuando deseemos guardar una nueva persona en nuestro repositorio, el código a utilizar sería así:

private void SaveFamilyNameCommand(string name)
{
   _familySrv.Save(new Person { Name = name});
   _familySrv.Flush();

   Family = new ObservableCollection<Person>(_familySrv.All);
   RaisePropertyChanged(()=> Family);
}

La aplicación que les dejo de ejemplo, en la vista principal tiene dos TextBox, uno para que escriba su nombre y otro para que adicione los nombres de su familia.

Después de escribir su nombre y guardar y después de entrar nombres de sus familiares, puede cerrar la aplicación y volverla a abrir para ver cómo los datos se persisten.

El ejemplo requiere MVVM Light y Newtonsoft.json. Source

Salu2

[IT] Outlook.com con dominio propio

Hola,

Hace unos días q llevo intentando migrar a Outlook.com para probar que tal va.

He leído algunos POST sobre cómo conectar GMAIL a Outlook y así estar al día sobre lo que por allí recibimos desde una única interfaz. Si aún no sabes cómo hacerlo, puedes  ver este post de Pilar con video incluido.

El problema que algunos nos encontramos es que en todos los casos se usa nuestra dirección de Outlook como dirección de re-envío. Para los que usamos cuentas personales (dominios propios: odelvalle.com) para acceder a live, hacer esto  implica re-enviar todo el tráfico de nuestra cuenta GMail a nuestro servidor de correo.

Para evitar esto, intenté cambiar mi cuenta outlook pero me avisó que perdería la conexión de todos los dispositivos asociados a esa cuenta live (malo malo). Busqué si se podía crear una nueva cuenta pero eso implicaría tener 2 accesos a live, una con mi correo personal y la otra con la nueva cuenta outlook (esto tampoco me convence)

Dedicando un ratico cada mañana a buscar posibles soluciones, hoy encuentro una: :

Crear un alias en outlook.com es la manera que tenemos de unir/asociar varias direcciones de correo electrónico a una sola. 

Al crear el Alias, Outlook.com te enviará un correo de verificación a tu cuenta personal (live) para asegurarse que el Alias está correctamente asociado.

y ya estamos listos. Podemos seguir los pasos que nos cuenta Pilar en su post y utilizar el alias de outlook como dirección de re-envío, de esta forma los correos de GMAIL no pasarán por nuestro pequeño e indefenso servidor e irán directamente al grande de Outlook.com.

Salu2

POO–Responsabilidades

“Hay una diferencia entre programar orientado a objetos y pensar orientado a objetos”

Debatiendo hoy en el trabajo sobre la funcionalidad que debería tener una toolsbox, salió uno de esos temas que me encantan. ¿Dónde debe estar el código asociado a un clic de un botón?

Responsabilidades

Mucho más allá de si la pregunta se responde aplicando un Chain of Responsibility Pattern, dentro se esconde uno de los pilares de la POO, la Especialización. Los objetos mientras mayor sea su especialización, mejor podremos definir su comportamiento.

¿Qué quiere decir esto? Pues que la responsabilidad de cada objeto debe ser solo, la que permita cumplir los objetivos por el cual fue creado.

Un avión vuela (por suerte). Nosotros desde fuera vemos un conjunto, pero dentro del avión hay miles de objetos que tienen una responsabilidad específica y que entre todos, hace que el avión vuele. Creo que excepto en las teles de la antigua URSS (le quitabas piezas y seguían funcionando), todo objeto tiene una responsabilidad que permite lograr una funcionalidad superior.

¿Que es una toolsbox? pues un panel de botones y nada más. Cuando compramos un panel de botones este no incluye para qué se usa cada botón o qué hace cada botón. Si compramos un interruptor eléctrico, este por si solo no apaga ni enciende la luz, incluso, puede llegar a realizar funciones explosivas si conectas incorrectamente los cables (que me pregunten a mi con 11 años la que lié).

Nuestra toolsbox, tiene botones (como casi todas) y el objetivo que cumplirá cada botón debería ser independiente a la misma. Un botón “dentro de la toolsbox” tiene estados cuyos cambios son notificados al exterior para quien quiera hacer algo que lo haga.

Lo mismo pasa con nuestro avión, mueves los mandos de vuelo y giras, esto no ocurre porque las aletas y el mando sean un único e inseparable objeto, sino porque el mando cambia de estado y notifica a todo aquel que pueda estar interesado para que haga algo. Las aletas y seguramente muchos objetos más dentro de un avión, están escuchando continuamente para saber si los mandos de vuelo han cambiado de posición(estado).

Vean que para definir cual debe ser la responsabilidad de mi  toolsbox, me he basado en todo momento en ejemplos de la vida real.

En el evento que di sobre POO en SecondNug (aquí tenéis los apuntes) cuando se analizaba la crisis del software, se definió como objetivo de la programación orienta a objetos el acercamiento del ordenador al problema y no del problema al ordenador, lo cual significa que debemos intentar en todo momento modelar los problemas existentes en la vida real analizándolo como lo que son, cosas que ocurren en la realidad. Esto era y seguramente aún es, el paradigma de la POO.

El otro día leía un artículo de Eduard sobre knockout y había una línea de texto que decía: "el código javascript es totalmente ignorante del DOM y trabaja tan solo con el viewmodel. Separación de responsabilidades.” ¡Atentos! que en este artículo se habla de separar la responsabilidad entre el HTML y el Javascript… (si digo yo esto en una entrevista de trabajo hace unos años, ya me dirán ustedes que hubieran pensado de mi)

Seguramente hoy por hoy aún queda mucho por hacer, pero da gusto como cada vez más intentamos llevar a la más mínima expresión la separación de responsabilidades. Mi opinión es que mientras menor sea la responsabilidad de un objeto, siempre que cumpla su objetivo, mejor y más fácil será de mantener.

Por cierto, para no dejarles sin saber, la toolsbox terminó con N botones que no saben lo que hacen pero que notifican a quien pueda interesar los estados de onBeforeClick y onClick. (espero no ser yo quien tenga que conectarla)

Salu2

Mensajes de browser a browser (Web Socket)

He estado trabajando últimamente en un proyecto en el que necesitaba comunicación entre instancias distintas de browsers en tiempos lo más real posible.

La solución se desprende, Web Socket con HTML5

La lógica que necesitamos en el servidor es simple, transmitir un mensaje que viene de un cliente, al resto de los clientes conectados.

En la parte del servidor quiero la menor lógica posible, así podré reutilizarlo en distintos proyectos. Los mensajes van de clientes a clientes, por lo que la responsabilidad del servidor en este caso debe ser solamente la de comunicación.

Para implementar el servidor he usado Fleck, un Web Socket que ya existe para NET y el cual recomiendo muchísimo, un código claro y fácil de entender si te pica la curiosidad y quieres conocer internamente cómo funciona.

Server

De momento vamos a crear una aplicación de consola para hospedar a nuestro Socket Server.

class Program
{
    static void Main()
    {
        FleckLog.Level = LogLevel.Debug;

        var socketManager = new MessagesWebSocket();
        socketManager.Start();

        Console.ReadLine();

        socketManager.Close();
    }
}

La clase MessagesWebSocket tendría:

class MessagesWebSocket
{
    private readonly List<IWebSocketConnection> _allSockets;
    private readonly WebSocketServer _server;


    public MessagesWebSocket()
    {
        _allSockets = new List<IWebSocketConnection>();
        _server = new WebSocketServer(ConfigurationManager.AppSettings["socketServer"]);
    }

    public void Start()
    {
        _server.Start(socket =>
        {
            socket.OnOpen = () =>
            {
                Console.WriteLine("Open client connection!");
                _allSockets.Add(socket);
            };

            socket.OnClose = () => _allSockets.Remove(socket);
            socket.OnMessage = message => _allSockets.Where(s=> s != socket).ToList().ForEach(s => s.Send(message));
        });
    }

    public void Close()
    {
        _allSockets.ForEach(s => s.Close());
        _server.ListenerSocket.Close();
    }
}

Si has trabajado con Socket verás que no hay mucha diferencia a lo que se hacía hasta ahora, incluso, la clase WebSocketServer de Fleck usa internamente System.Net.Sockets.

Nuestra clase MessagesWebSocket tiene dos métodos, Start & Stop.

Start nos permite abrir la conexión y quedarnos a la escucha de cualquier petición de conexión de algún cliente. Cuando un cliente previamente conectado envía un mensaje al servidor, este simplemente toma el mensaje tal cual y lo envía al resto de clientes conectados.

El servidor no interviene en absoluto en la estructura del mensaje que se envía, justamente lo que necesitamos. Entender los mensajes que se envían los clientes será siempre responsabilidad de ellos.

Client

Si hablamos de clientes WEB, la moda en comunicación se llama JSON! Así que vamos a hacer que este sea el formato que usen los mensajes enviados entre clientes.

Para que todo el tema de web socket y json nos quede fuera de la lógica de cualquier página o proyecto, vamos a encapsular toda la funcionalidad dentro de un objeto en Javascript que nos permita enviar y recibir mensajes sin importarnos cómo.

var WebSocketHelper = function (server, onMessage, onError)
{
    var w = window;
    var connection;

    var reciveData = onMessage || false;
    var error = onError || false;

    // if user is running mozilla then use it's built-in WebSocket
    w.WebSocket = w.WebSocket || w.MozWebSocket;

    // open connection
    try
    {
        connection = new w.WebSocket(server);
    }
    catch (connErr)
    {
        if (error) error("Open connection error: " + connErr);
        return;
    }

    // only for debug propose
    connection.onopen = function ()
    {
        //alert('Connected.');
    };

    connection.onmessage = function (d)
    {
        var result = jQuery.parseJSON(d.data);
        if (reciveData) reciveData(result);

        return false;
    };

    connection.onerror = function (wsErr)
    {
        if (error) error("Connection error: " + wsErr);
        connection = null;
    };

    this.SendCommand = function (obj)
    {
        try
        {
            var jsonString = JSON.stringify(obj);
            connection.send(jsonString);
        }
        catch (sendErr)
        {
            if (error) error("Send message error: " + sendErr);
        }
    };
};

Vamos por parte.

1- Al objeto WebSocketHelper le pasamos tres parámetros: la dirección del servidor, una función (opcional) que se ejecutará cuando nos llegue un nuevo mensaje y otra función (también opcional) que se ejecutará si encontramos algún error.

2- Instanciamos un nuevo objeto WebSocket, y aquí entramos en las diferencias entre browsers de toda la vida. Firefox tiene un objeto MozWebSocket mientras Chrome e Internet Explorer (v10) usan WebSocket.

3- Luego de instanciado el socket, intentamos abrir la conexión con el servidor, si todo sale bien, estamos listos para enviar y recibir datos mediante el socket.

4- El evento onmessage es quien me permite capturar los mensajes que llegan desde el servidor. La función asociada a este evento toma el mensaje recibido y lo transforma a un objeto javascript usando jQuery.parseJSON. Al tener la información recibida como objeto javscript, se ejecuta la función que hemos pasado al WebSocketHelper pasando como parámetro el objeto recibido.

5- Para enviar un objeto al servidor el proceso es parecido. Se usa la función pública SendCommand y se pasa como parámetros el objeto a enviar. Esta función internamente convierte el objeto en string y lo envía mediante el socket al servidor.

¿Cómo funciona esto desde una página?

Primero que todo hay que llegar a un acuerdo entre clientes, podemos enviar cualquier objeto javascript mediante el servidor pero es necesario que los clientes sepan de que va el asunto, porque de lo contrario sería como pedir una cerveza y que de pronto te lleguen melones, quesos, tomates, gambas y sandias ( y lo peor es que intentes algo porque creas que son cervezas).

En mi caso he usado una estructura de objetos muy simple. Internamente cada objeto que envío tiene una propiedad llamada command que define el tipo de mensaje que es.

var commands = { stop: "stop", start: "start", game: "game", reset: "reset", gameover: "gameover" };

Inicializando el socket server y recibiendo datos desde el servidor:

var socket = new WebSocketHelper("ws://192.168.100.64:8181", function (cmd)
{
    switch (cmd.command)
    {
        case commands.gameover:

            // GAME Over
            break;

        case commands.start:
            
            alert("Welcome {0}. Are you ready?".format(cmd.player));
            break;

        default: throw new Error("Invalid Command on socket server.");

    }
});

Enviando mensajes:

socket.SendCommand(
{
    command: commands.start,
    player: 'Pepe el loco',
    device: 1,
    language: 'es'
});

y con esto ya tenemos una comunicación simple de browser a browser.

Más adelante veremos otro ejemplo en el que vamos a darle más responsabilidad al SocketServer enviando comandos recibidos desde una Kinect a clientes Web y ya de paso, convertiremos nuestro WebSocket en un servicio Windows.

Salu2

Navigator para WP7 en MVVM

Otro tema que estaba pendiente...

Cuando empecé a estudiar y testear cosas de WP7 con MVVM, una de los detalles que más me molestaban era tener que navegar entre páginas usando el code behind.

Es verdad que desde el ViewModel puedes tener acceso al NavigationService, pero esto sería una muy mala práctica de cara a los test unitarios. Por otra parte, desde dónde puedo capturar los parámetros pasados a una vista es siempre el método OnNavigatedTo que tenemos en el Code Behind.

Una tarde escuchando una charla de Josue sobre WP7, comentó que se encontraba desarrollando una aplicación llamada WPControla. Soy de los que piensa que una de las mejores maneras de tomar buenas prácticas en los desarrollos es mirar mucho código, cualquiera, no importa de quien sea porque siempre te ayudan a comparar y sacar conclusiones sobre lo que se debe o no hacer. 

En la propia charla le pregunté a Josue si podríamos descargarnos el código de la aplicación y como siempre, nos dio acceso al repositorio.

Mirando el código de esta aplicación descubrí algo que me llamó mucho la atención, dentro del namespace WPControla.Client.Services había una clase llamada NavigationService. Me imaginé que esta clase, al implementar una interfaz sería una solución a lo que tanto me había molestado hasta el momento, poder navegar entre Views desde el ViewModel sin afectar los test.

Me costó entender cómo funcionaba porque en el repo no está toda la funcionalidad aún implementada, así que le pregunté directamente a Josue si esto era lo que me imaginaba y cómo había pensado en resolver esto, su respuesta no se hizo esperar. Gracias Josue!

Con permiso del Master, vamos a intentar explicar la solución que implementa  WPControla.

Todo parte de una clase llamada NavController en la cual se empieza definiendo un singleton para el acceso a una única instancia. También contamos con un Dictionary que nos permite registrar y referenciar las vistas mediante “alias”.

registeredViews.Add("Start", new Uri(@"/MainPage.xaml", UriKind.Relative));

En mi caso, cambié el Dictionary utilizado:

static Dictionary<String, Uri> registeredViews = new Dictionary<String, Uri>();

por:

private static readonly Dictionary<Pages, Uri> _registeredViews = new Dictionary<Pages, Uri>();

Pages es un enumerado, esto no implica ninguna mejora a la solución planteada por Josue, más bien es un gusto personal, no me gusta trabajar con string porque soy muy despistado y siempre los escribo mal, así que me ahorro errores de ejecución usando enumerados.

La clase define  tres sobrecargas sobre el método NavigateTo. Una sobrecarga nos permite navegar a una vista sin pasar parámetros, en la segunda, podemos incorporar parámetros pasados por QueryString y en la tercera nos vamos a detener:

public void NavigateTo(String navigationTarget, Action<NavigationEventArgs> onNavigated)

Esta sobrecarga incluye un Action<NavigationEventArgs> como parámetro, el objetivo es poder tomar una acción en el momento en que se navegue de una vista a otra. Internamente la clase navController captura el evento Navigated de PhoneApplicationFrame y cuando este ocurre, ejecuta nuestra acción.

/// <summary>
/// Este evento se lanza cuando hemos navegado a una página.
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
void root_Navigated(object sender, NavigationEventArgs e)
{
    if (NavigationMethod != null)
    {
        NavigationMethod(e);
        NavigationMethod = null;
    }
}

Este método de la forma que está escrito, no nos permite capturar el Navigated cuando el NavigationMode es Back, o sea, cuando vamos de regreso. Para solucionarlo solo necesitamos eliminar la línea de código que asigna null al NavigationMethod y no olvidar desasignar el evento cuando regresemos, porque de lo contrario navegando hacia atrás y hacia adelante multiplicará la cantidad de veces que se ejecuta nuestra acción.

void RootNavigated(object sender, NavigationEventArgs e)
{
    if (_navigationMethod == null) return;

    _navigationMethod(e);

    if (e.NavigationMode != NavigationMode.Back) return;
    var rootFrame = (PhoneApplicationFrame)Application.Current.RootVisual;
        
    rootFrame.Navigated -= RootNavigated;
}

Otra particularidad de esta sobrecarga es que mediante el parámetro NavigationEventArgs tenemos acceso a la View que estamos navegando mediante la propiedad Content, a su vez, mediante la View tenemos acceso al DataContext que en una arquitectura MVVM sería el ViewModel. Esta estructura pudiera ser utilizada para inicializar objetos complejos cuando navegamos de una vista a otra (luego veremos un ejemplo).

Ya que estamos creando métodos de navegación, adicioné a esta clase un método que nos permita hacer Back por código.

public void NavigateToBack()
{
    var rootFrame = Application.Current.RootVisual as PhoneApplicationFrame;
    if (rootFrame == null || !rootFrame.CanGoBack) return;

    rootFrame.GoBack();
}

La magia para que todo esto se integre con nuestros ViewModels llega ahora:

Definimos una interfaz con los distintos métodos para la navegación que necesitamos en nuestra aplicación, hacemos que un servicio implemente dicha interfaz y lo usamos en el constructor de los distintos ViewModels.

Un servicio de navegación que utilice NavController quedaría como el siguiente:

public interface INavigatorService
{
    void GotoMvvmView1();
    void GotoMvvmView1(DataItem param);

    void GoBack();
}

public class NavigatorService : INavigatorService
{
    public void GotoMvvmView1()
    {
        NavController.Current.NavigateTo(NavController.Pages.MvvmView1);
    }

    public void GotoMvvmView1(DataItem param)
    {
        NavController.Current.NavigateTo(NavController.Pages.MvvmView1, 
            args =>
            {
                if (args.NavigationMode != NavigationMode.New) return;

                var view1Model = ((FrameworkElement) (args.Content)).DataContext as View1ViewModel;
                if (view1Model != null) view1Model.Initialize(param);
            });
    }

    public void GoBack()
    {
        NavController.Current.NavigateToBack();
    }
}

Observen como estamos ejecutando una acción en el momento en que llegamos a la vista a la que deseamos navegar. Esta acción accede al ViewModel e inicializa parámetros necesarios con los datos que se pasan al método GotoMvvmView1.

A mi este mecanismo no me gusta  (cuestión personal), no sé si será buena o mala práctica, pero me cuesta tener que acceder a métodos del ViewModel desde este punto.

Para solucionar este problema he incorporado a la clase NavController un Dicctionary para pasar datos entre vistas.

/// <summary>
/// Navigation Parameters 
/// </summary>
public static IDictionary<string, object> Parameters { get; set; }

Como NavNavigator es independiente de nuestros ViewModels mediante una interfaz, tenemos que adicionar a la misma la utilización del Dictionary. La interfaz vista anteriormente ahora nos quedaría así:

public interface INavigatorService
{
    IDictionary<string, object> Parameters { get; set; }

    void GotoMvvmView1();
    void GotoMvvmView1(DataItem param);

    void GoBack();
}

y su implementación sería…

public class NavigatorService : INavigatorService
{
    public IDictionary<string, object> Parameters
    {
        get { return NavController.Parameters; }
        set { NavController.Parameters = value; }
    }

    public void GotoMvvmView1()
    {
        NavController.Current.NavigateTo(NavController.Pages.MvvmView1);
    }

    public void GotoMvvmView1(DataItem param)
    {
        NavController.Current.NavigateTo(NavController.Pages.MvvmView1, 
            args =>
            {
                if (args.NavigationMode == NavigationMode.Back) return;

                NavController.Parameters = new Dictionary<string, object> { { "item", param} };
            });
    }

    public void GoBack()
    {
        NavController.Current.NavigateToBack();
    }
}

Después de tener esto solo nos queda pasar el servicio de navegación en el constructor de nuestros ViewModels y acceder a los distintos métodos para navegar.

/// <summary>
/// Initializes a new instance of the MainViewModel class.
/// </summary>
public MainViewModel(IDataService dataService, INavigatorService navigator)

private void GotoView1Command()
{
    _navigator.GotoMvvmView1(_item);
}

Quizás pienses que a esta altura, cuando ya WP7 solo tendrá una próxima actualización y las cosas cambiarán de cara a WP8 y a la nueva interfaz de W8 (antes Metro), ya no tienen mucho sentido. Puedes echarle una ojeada a este post sobre W8 del propio Josue y seguramente habrá cosas que te resulten familiar.

Salu2

Código del ejemplo

AsyncWorkManagerHelper para WP7

Hace mucho que tenía este artículo y este código en el tintero por repasar y publicar. Se trata de un Helper para ejecutar tareas en un agente de WP7 de manera asíncrona.

Hace 1 año aproximadamente, Peter Torr publicaba un artículo en tres partes explicando el trabajo con los agentes en background para WP7. Los enlaces a las tres partes son:

1- Background Agents - Part 1 of 3
2- Background Agents - Part 2 of 3
3- Background Agents - Part 3 of 3

En la segunda parte de la seria se discute un Helper para realizar tareas en segundo plano y esperar que estas terminen para poder notificar al agente el resultado de la ejecución.

El helper da una limpieza a nuestro código muy buena y nos permite olvidarnos de todo el proceso asíncrono. Sin embargo, si queremos extender el uso del helper más allá de un agente y utilizarlo en nuestra aplicación, encontramos que carece de alguna funcionalidad.

1- No se tiene control de lo que va sucediendo con las tareas que se van ejecutando hasta que no termina todo el proceso.
2- Si yo necesito que las tareas se ejecuten de 1 en 1 o de 2 en 2, o de N en N, tampoco tendría el control sobre ello.

Entiéndase que el helper fue escrito para ayudar con las tareas en background de un agente y en estos casos pocas veces importa lo que está sucediendo hasta que no termina todo el proceso.

Dispuesto a poder utilizar el código del Helper en cualquier tarea asíncrona que necesite ejecutar mi aplicación de WP7, le hice algunas modificaciones al código.

FIFO para las tareas.

First In, First Out. El código de Peter ejecuta directamente cada tarea cuando se adiciona la misma al Helper. En realidad estas ejecuciones son bloqueadas hasta que un ManualResetEvent es seteado cuando se ejecuta el Start o el WaitAll

/// <summary>
/// Schedules a work item to begin
/// </summary>
/// <param name="work">The work to perform</param>
/// <remarks>The worker thread is blocked on the startEvent so that the work
/// doesn't complete before the client is ready to handle the completion event
/// </remarks>
void BeginWorkItem(WorkloadInfo<TParam, TResult> work)
{
  lock (this)
  {
    outstandingItems++;
  }

  ThreadPool.QueueUserWorkItem(delegate
  {
    // Wait until it's OK to start
    startEvent.WaitOne();
    try
    {
      // Method is responsible for completing itself if it didn't fail
      work.Method(work.Parameter, work);
    }
    catch (Exception ex)
    {
      // Complete with a failure case
      work.NotifyFailure(ex);
    }
  });
}

Si queremos controlar la cantidad de tareas ejecutándose a la vez, este mecanismo no nos vale, por lo que he creado un Queue (FIFO en NET) para almacenar las tareas y poder controlar su ejecución.

/// <summary>
/// FIFO to Tasks
/// </summary>
private readonly Queue<WorkloadInfo<TParam, TResult>> _queue;

El la clase AsyncWorkManager ahora tiene 2 constructores, en uno de ellos podemos indicar el límite de tareas que se ejecutan simultáneamente.

Para poder conocer el estado de cada tarea en el momento en que se ejecutan, se ha adicionado un evento (OnCompleteWorkItem) a la clase WorkLoadInfo que es disparado justo al concluir la ejecución de la misma.

/// <summary>
/// Completes the work item with a successful result
/// </summary>
/// <param name="result">The result of the operation</param>
/// <remarks>This method is called by the worker Method once it has completed its task</remarks>
public void NotifySuccess(TResult result)
{
    MarkAsComplete();
    Result = result;

    if (OnCompleteWorkItem != null) OnCompleteWorkItem(this, EventArgs.Empty);
    _parent.CompleteWorkItem();
}

/// <summary>
/// Completes the work item with an error
/// </summary>
/// <param name="error">The error to report</param>
/// <remarks>This method is called by the worker Method if it fails its task</remarks>
public void NotifyFailure(Exception error)
{
    MarkAsComplete();
    Error = error;

    if (OnCompleteWorkItem != null) OnCompleteWorkItem(this, EventArgs.Empty);
    _parent.CompleteWorkItem();
}

La clase AsyncWorkManager tiene dos métodos por los cuales se puede iniciar el proceso. Start y WaitAll.

Start

El método inicia la ejecución de todas las tareas y no espera por su finalización. En la versión original del Helper el Start se ejecuta en el mismo hilo desde el cual es llamado y, si en nuestro caso queremos controlar la cantidad de tareas que se van ejecutando esto tampoco nos vale, así que también se ha modificado para que se ejecute en un ThreadPool diferente.

/// <summary>
/// Starts performing work, if not already happening.
/// </summary>
/// <remarks>This method is implicitly called by the WaitAll methods</remarks>
public void Start()
{
    _startNewEvent.Set();

    lock (this)
    {
        if (_queue.Count == 0)
        {
            CompleteWorkload();
            return;
        }

        // Work has already been completed
        if (_completionEvent.WaitOne(0)) return;

        // Reset the completion event to be waited on
        _completionEvent.Reset();

        _outstandingItems = _queue.Count;
    }

    ThreadPool.QueueUserWorkItem(delegate
    {
        // Release the threads waiting to do work
        while (true)
        {
            if (_executingOperations == _concurrentOperations && _concurrentOperations != 0) _startNewEvent.Reset();

            _startNewEvent.WaitOne();

            var work = _queue.Dequeue();
            BeginWorkItem(work);

            if (_queue.Count == 0) break;
        }
    });
}

Una particularidad del cambio realizado es que si usamos el constructor sin parámetros de la clase AsyncWorkManager, no se controla la concurrencia y todas las tareas son ejecutadas a la vez.

WaitAll

Este método tiene dos sobrecargas, una sin parámetros que espera infinitamente a que todas las tareas se hayan ejecutado (ojo que esto detiene el hilo en el que se haga la llamada al método) y otro que espera un tiempo (timeout) y aborta en caso de que todas las tareas no se hayan finalizado.

Después de los cambios, un ejemplo de cómo se podría usar el Helper sería este:

var calendarsWorkManager = new AsyncWorkManager<Account, IEnumerable<Calendar>>(concurrentsTask:1); 

GetAccounts(delegate(object o, AccountsEventArgs args)
{
    foreach (var account in args.EntityList)
    {
        switch (account.Source)
        {
            case Enums.SourceProvider.Google:

                var rGoogle = calendarsWorkManager.AddWorkItem(SyncGoogleCalendars, account);
                rGoogle.OnCompleteWorkItem += delegate
                {
                    if (rGoogle.Error == null) calendarList.AddRange(rGoogle.Result);
                };

                break;
            case Enums.SourceProvider.Live:

                var rLive = calendarsWorkManager.AddWorkItem(SyncLiveCalendars, account);
                rLive.OnCompleteWorkItem += delegate
                {
                    if (rLive.Error == null) calendarList.AddRange(rLive.Result);
                };

                break;
            case Enums.SourceProvider.Exchange:

                calendarList.Add(ExchangeCalendar(account));

                break;
        }
    }

    calendarsWorkManager.WorkComplete += (sender, a) => onCalendarList(this, new CalendarsEventArgs(calendarList));
    calendarsWorkManager.Start();
});

En principio la funcionalidad es la misma, excepto que podemos conocer y hacer algo cuando cada tarea se termina de ejecutar (onCompleteWorkItem), podemos indicar la cantidad de tareas ejecutándose a la vez (concurrentsTask:1) y ejecutar el inicio del proceso mediante Start sin que el hilo quede bloqueado.

Adjunto el código del Helper modificado por si a alguien le vale.

Un salu2

#region en C#

Acabo de leer en twitter un comentario que dice:

“‏#region in C# only has 2 purposes: to add unnecessary noise, or when you think it helps, it's actually telling you how much your class sucks because if you feel the need to 'group' things into regions, you generally need to separate the code into multiple classes”

El comentario se refiere a dos formas diferentes de usar #region, uno sería quien usa las regiones para identificar zonas privadas o públicas, o para identificar constructores del resto de la lógica en una clase y, el otro grupo se refiere a quienes lo usan para agrupar funcionalidad o lo que es lo mismo, lógicas diferentes dentro de una misma clase.

Al primer grupo, le define el uso de regiones como “ruido”, un calificativo desde mi punto de vista que pudiera ser discutible  

Sobre el comentario hacia el segundo grupo no se le puede quitar una pizca de razón. Si una clase es lo suficientemente grande como para que te sea “molesta a la vista”, puedes estar seguro que necesitas un refactoring antes que varios #region

… aquí tienes un claro ejemplo de lo que nunca se debería hacer:

cu…

[OT] Return to live…

Hace ya bastante tiempo que un día sí y otro también, solo sabemos escuchar hablar sobre las nuevas tecnologías que nos vienen desde Microsoft: Metro, W8, WP8, nueva versión de NET, de MVC, de EF… 

Si a eso le sumamos andadoras por WebGL con three.js, Kinect con javascript y HTML 5 que últimamente me tocan porque sí… poco tiempo queda para escribir algo.

Aprovechando que agosto parece que viene más “relajado” y que finalmente, después de cambiar a WP, pienso empezar a publicar cosas en mi blog (www.odelvalle.com) sería buen momento para retornar a la vida…

Para no dejar abandonado (no podría) a geeks.ms, este primer post viene siendo algo así como un [TestMethod] desde Live Writer hacia el resto del mundo

Pronto más…
salu2

DDD: 2- Framework de IoC (Service Pack 1)

Después de la última sacudida recibida por la encapsulación del Container que hicimos en el artículo anterior, sacamos este Service Pack 1 y de paso cuento un poco cómo llegamos aquí.

Cuando me pasan estas cosas, siempre recuerdo el pasaje de una lectura que tengo por casa…

“Denis Cochin preparo un estudio sobre Química y lo presento a Pasteur. El trabajo comenzaba con las palabras. “Se sabe que...“

- ¿Que es lo que se sabe? - Interrumpió Pasteur al leerlo. - No se sabe nada.
- Pero señor - Contesto Cochin - lo que iba a citar es un trabajo de usted.

- No importa - replico Pasteur. - Yo podría haberme equivocado. Empiece Ud. de nuevo”

Tras los comentarios de Unai y Eduard más la referencia al artículo de Mark sobre el patrón o anti-patrón Service-Locator (Martin Fowler, 2004), había que profundizar más en el tema, así que sin pensarlo dos veces me compré el libro de “Dependency Injection in .NET” el cual recomiendo muchísimo por la claridad en el contenido, además de estar orientado directamente a NET.

En el libro, cuando Mark habla del Service Locator como un anti-patrón, dice: “Some people consider it a proper design pattern, whereas others (me included) consider it an anti-pattern.”

Tras esta definición no puedo evitar preguntarme ¿Y en qué bando me pongo yo? Es evidente que la opinión de Eduard, Unai, Mark y seguramente la de muchos otros, pesa muchísimo, así que lo más probable es que termine más rápido si busco alguna deficiencia en la implementación anterior que me lleve finalmente a verlo como ellos.

Tras no mucho tiempo… me imaginé la siguiente situación:

Tengo varios controladores (MVC) que usan inyección de dependencia con uno o varios servicios (Application services), tengo servicios que usan dependencias a uno o más repositorios, tengo varios repositorios que usan dependencia a una unidad de trabajo, tengo una unidad de trabajo que depende de una cadena de conexión. En esa situación, tendré en mis controladores llamadas al Resolve del container para crear los servicios, en los servicios llamadas al Resolve para crear instancias de los repositorios, tendré también llamadas al Resolve en los repositorios para recuperar la unidad de trabajo y así en toda mi arquitectura...

Salta a simple vista que mis controladores dependen de mis servicios y del Service Locator. Los servicios dependen de los repositorios y del Service Locator, los repositorios dependen de la unidad de trabajo y del Service Locator. ¿Qué pasa si quiero reutilizar los repositorios? ¿O si quiero reutilizar los servicios? ¿O si quiero reutilizar mi unidad de trabajo? Pues que en todo momento dependeré del Service Locator…

No seguí buscando… mi objetivo era estar desacoplado del Framework de IoC y terminé atando toda la arquitectura.

¿Cómo soluciono esto entonces?

-Constructor Inyection
-Property Injection
-…

Si mis controladores recibieran los servicios que necesitan para trabajar mediante el constructor, no necesitaría una referencia al Service Locator… y lo mismo pasa en toda la cadena de inyección.

¿Cómo funciona esto? Imaginen que tengo…

Controller(IService srv) – Service(IRepository repo) – Repository(IUnitofWork uow) – UnitOfWork()

1- Un controlador necesita una instancia de un servicio, se intenta crear una instancia de ese servicio.
2- Para crear el servicio se necesita un repositorio, se intenta crear una instancia del repositorio.
3- Para crear el repositorio se necesita una unidad de trabajo, se intenta crear la unidad de trabajo.
4- Se crea la unidad de trabajo (no depende de nadie).
5- A partir de aquí, se inyecta la unidad de trabajo al repositorio, el repositorio al servicio y el servicio al controlador.

Este algoritmo me dice que todo empieza desde un punto único. A este punto Mark lo llama Composition Root. “A COMPOSITION ROOT is a (preferably) unique location in an application where modules are composed together.”

Un DI Container es quien me dice quién es el Container utilizado en mi aplicación y el encargado de componer todo el grafo de objetos. Este debe ser referenciado únicamente desde el Composition root (De aquí que Eduard y Unai no vean la necesidad de abstraer el Container) y se inicializa solo una vez en todo el ciclo de vida de la aplicación.

Conociendo un poco más que ayer, decidí hacer “refactoring” a todo lo visto ayer (Por llamarle de una forma menos dura al hecho de borrar todas las interfaces e implementaciones de mi Service Locator). Después de un rato, me quedó esto:

Mi DI Container. …

¿Quién sería mi Composition Root? Pues ya esto depende del tipo de aplicación que se vaya a crear, ya que cada aplicación puede tener una definición diferente para su “único punto de entrada”. Por ejemplo, para una aplicación MVC, Mark aconseja un IControllerFactory, aunque si es para MVC3, yo prefiero el IDependencyResolver.

Mi Composition Root para MVC3 sería:

Aquí puedes encontrar un pequeño post de Steve explicando la implementación anterior.

Para el caso de un servicio WCF me gustó la forma en que lo implementaron en la guía de arquitectura N Layer donde se implementa la interfaz IInstanceProvider:

"As you can see, it took me a couple of years of intense use to realize the shortcomings of SERVICE LOCATOR and that better alternatives existed. For this reason, I find it easy to understand why so many developers find it attractive…” (Gracias Mark)

Los test…

El problema de los test está en que no tenemos un evento al cual nos podamos subscribir ni interfaz que implementar… Entonces, ¿Cómo creo los test sobre el IoC Container? by Scott…

Basados en las interfaces IA, IB y las clases A y B que escribimos en el artículo anterior, tendríamos los siguientes test:

Los elementos de configuración, ya podemos inyectarlos tal y como nos pedía Juanma:

Gracias a Unai y a Eduard por hacer posible esta mejora…

PD: Aún no he probado los módulos implementados para MVC3 o para WCF… ya os contaré

Salu2

DDD: 2- Framework de IoC (parte 2)

En el artículo anterior implementamos todas las interfaces necesarias para usar algunos elementos de configuración a nivel de aplicación. Entre estos elementos estaba el Framework de IoC.

En ese mismo artículo explicábamos por qué decidimos inyectar al Framework de dependecia, así que hoy nos dedicaremos a implementar todas las interfaces y realizar algunos test.

Antes de empezar, deciros que he realizado una pequeña modificación a la interfaz IContainerConfiguration que vimos en el artículo anterior. Soy de los que cree que cuando algún código (mio o no) queda digno de “admirar” (lo cual no quiere decir “correcto” ), me quedo rato mirándolo aún días o semanas después de haberlo implementado. Esto, además de parecer que pierdo el tiempo, me  ayuda a ver posibles refactoring que en su momento no vi.

En uno de esos momentos de “bobería” me di cuenta que la interfaz IContainerConfiguration no necesita saber el QulifiedName para nada y que con el tipo era suficiente. Es verdad que de alguna forma debo recuperar el tipo, pero de eso que se encargue quien implemente la interfaz.

IContainerConfiguration ahora quedaría así:

public interface IContainerConfiguration
{
    Type IocObjectType { get; }
}


Después de hecho el cambio, entramos en materia.

Pensando con el corazón y no en el performance, voy a utilizar como Framework de inyección de dependencia el Unity de Microsoft, pero recuerden, de la forma que lo hemos implementado podríamos usar cualquiera siempre que implementemos la interfaz IContainer.

Para temas de configuración, usaré el archivo de configuración de la aplicación. Al igual que el framework de IoC, podríamos obtener la configuración de cualquier otro lado tan solo implementando las distintas interfaces.

Empezamos con la implementación del UnityContainer, nuestro único requerimiento es implementar la interfaz IContainer.

La idea no es entrar a analizar el UnityContainer de Microsoft, sino me gusta, uso otro y nada cambia en toda mi aplicación. De cualquier forma, por detallar un poco la implementación de la interfaz, vemos la inicialización de Unity en el método que provee la interfaz (InitializeContainer), luego usamos el Container para satisfacer los dos métodos de la interfaz que retornan una instancia de un objeto basado en su interfaz (con o sin parámetro) y todo listo.

¿Hacemos entonces unos Test a ver qué tal? Ah no, que no puedo, primero tengo que implementar todo el tema de configuración. Pues lo que adoro de esta arquitectura es precisamente esto, sí, tengo que implementar el tema de configuración, pero como la misma sale de una interfaz, puedo hacerlo sin tener que llegar a implementar todo lo que se refiere al archivo de configuración.

Aquí implemento la interfaz de configuración para el IoC y retorno directamente el tipo que implementa el IContainer. (Nota: El tipo UnityContainer que retorno aquí no es el de Microsoft, es el mío que implementa la interfaz IContainer).

Voy a crearme unos objetos bien simples para realizar los test

Configuramos el Unity de Microsft para crear los Alias y los mapeos y vamos por los test.

<configSections>
  <section name="unity"
            type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
            Microsoft.Practices.Unity.Configuration" />
</configSections>

<unity>
  <typeAliases>
    <typeAlias alias="IA" type="Solution.Test.Infrastructure.IoC.IA, Solution.Test" />
    <typeAlias alias="IB" type="Solution.Test.Infrastructure.IoC.IB, Solution.Test" />
    <typeAlias alias="A" type="Solution.Test.Infrastructure.IoC.A, Solution.Test" />
    <typeAlias alias="B" type="Solution.Test.Infrastructure.IoC.B, Solution.Test" />
  </typeAliases>
  <containers>
    <container>
      <register type="IA" mapTo="A" />
      <register type="IB" mapTo="B" />
    </container>
  </containers>
</unity>

Los test:

Me encanta este momento…

Bien, pasemos del sentimentalismo y la adoración del color verde del Success y vayamos a la configuración. La implementación de la configuración del framework de IoC desde el archivo de configuración quedaría de la siguiente forma:

Recuerden que ya la propiedad que nos da el QualifiedName no pertenece a la interfaz, sin embargo sí que la implementamos cuando queremos obtener quién será nuestro  Framework de IoC desde la configuración.

Hagamos lo mismo para los Settings de mi aplicación:

Ahora ya podemos  implementar la interfaz que agrupa los elementos de configuración.

Vean que hemos tenido que definir propiedades que retornen un ConfigurationElement. Esto es requerido para poder leer las configuraciones del archivo de configuración, pero yo en ningún momento deseo que esos tipos sean conocidos por mi aplicación (recuerden que trabajamos ajenos a la tecnología que usemos). Es por eso que esta clase crea las propiedades concretas para la configuración como privadas y, las que usará mi aplicación (públicas) retornan la interfaz del tipo creado.

Por último, implementamos IGlobalSettings. Aquí me implemento un Singleton a nivel de aplicación para acceder a mi configuración. Dos razones, tengo un único punto de acceso (por eso el síngleton) y los datos que guarda mi configuración no cambian durante todo el ciclo de vida de la aplicación (por eso digo que es a nivel de aplicación)

Ya podemos ir a por los Test de configuración. El IoC ya lo probamos, por lo que con saber que el tipo retornado por la configuración es correcto (implementa IContainer), tengo suficiente

Antes de escribir los test, creamos la configuración en el archivo de configuración de la aplicación.

<configSections>
  <section name="Project"
        type="Project.Settings.Config.AppConfigurationSection, Project.Settings.Config"
        requirePermission="false" />
</configSections>

<Project>

  <Setting name="My Project DDD"
                languageDefault="es-ES"
                datetimeFormat="dd-MM-yyyy HH:mm"
                timeZoneOffset="1"  />

  <IocConfiguration unityType="Project.IoC.EnterpriseLibrary.UnityContainer,
                                                                        Project.IoC.EnterpriseLibrary" />

</Project>

y ahora sí…

Result:

y Chirrin-chirran….

DDD: 2- Framework de IoC (parte 1)

¿Por dónde empezamos hoy? Pues si conocemos de antemano la arquitectura DDD, sabremos que uno de los aspectos más importante en su implementación es la inyección de dependencia.

El concepto de aplicaciones orientadas al dominio explica claramente que debemos aislar la lógica del dominio de cualquier tipo de detalle técnico.

La “Guía de arquitectura N-capas orientada al dominio” nos dice…

“Esta capa debe ser responsable de representar conceptos de negocio, información sobre la situación de los procesos de negocio e implementación de las reglas del dominio. También debe contener los estados que refleja n la situación de los procesos de negocio, aun cuando los detalles técnicos se delegan a las capas inferiores….”

Resumiendo un poco, el dominio debe saber “Qué” se hace, pero nunca “Cómo” se hace…

Por otro lado, el concepto de una interfaz es un contrato que indica lo que se debe hacer, pero nunca incluye código de cómo se debe hacer… De aquí, que la forma de aislar el dominio en una arquitectura DDD de su implementación, sea mediante interfaces.

La importancia de la inyección de dependencia en este tipo de arquitectura es precisamente esta, inyectar instancias de objetos que saben “cómo” hacer algo mediante interfaces que indican “qué” se debe hacer.  Es lógico que los objetos que se inyecten deban implementar la interfaz, pero si no lo hacen ya se encargará el framework de avisarnos con un ruidoso error.

Para usar inyección de dependencia existen muchos frameworks. Algunos de ellos son:

-          Ninject
-          Unity
-          Castle.Windsor
-          Autofac
-          StructureMap

Aquí encontraras un buen debate sobre cuál es mejor o peor o cuáles son sus ventajas o desventajas.

http://stackoverflow.com/questions/4581791/how-do-the-major-c-sharp-di-ioc-frameworks-compare

A mí en esta parte siempre me entra la duda, si hablamos de un dominio que no es afectado por los detalles técnicos entonces, ¿debería preocuparme por saber cuál debe ser el Framework que usaré para inyectar dependencias? Bueno, tampoco pasemos olímpicamente de esto, claro que debía preocuparme por temas de performance… pero estos frameworks evolucionan y el que es mejor hoy, mañana puede ser peor.

¿Qué hago entonces? ¿Pues no les gustaría poder inyectar a quien te inyecta? ¿Nunca han querido pagar con la misma moneda?  Yo decidí inyectar el framework de inyección…

De lo que hemos visto, el objetivo para mí de un Framework de inyección de dependencia es precisamente retornarme una instancia de un objeto mediante su interfaz. Entonces, lo que necesito sería algo como esto:

public interface IContainer
{
  void InitializeContainer();
  T GetInstanceOf<T>();
  T GetInstanceOf<T, TParamType>(TParamType paramInjection);
}

Ahora necesito algún elemento de configuración que me indique cómo instanciar mi framework de IoC. ¿De dónde sale la configuración? Pues no lo sé, lo que realmente me importa es su contrato, no cómo lo haga. La interfaz para la configuración contiene una propiedad que me retorna el QualifiedName usado para crear el tipo concreto del framework de IoC.

public interface IContainerConfiguration
{
  string IocQualifiedName { get; set; }
  Type IocObjectType { get; }
}

Para combinar el Container con su configuración nos implementamos un Factory:

Hasta aquí ya tenemos definidas las interfaces…  pero ¿quién implementa estas interfaces? y lo más importante, ¿cómo se usaría al final?

Cada aplicación que hago, “debería” tener aspectos que son generales a nivel de toda la aplicación. Me refiero a parámetros cómo:

-          Formato de fecha que usaré por defecto
-          Idioma que usaré por defecto
-          Zona horaria en que se encuentra la aplicación

Estos parámetros son un poco a mi gusto personal, quiero olvidarme de si el formato de fecha/Hora tiene que ser o no independiente al idioma o si el servidor donde hospedo la aplicación está en América o el viejo continente, por eso predefino este tipo de datos. A estos parámetros se suma ahora mi Framework de IoC, que también será de uso general por toda la aplicación.

Cómo hemos repetido durante todo el artículo, en este punto no sé de dónde saldrá esta información. A algunos les será más útil sacarlo de base de datos y a otros del archivo de configuración de la aplicación, así que sigo creando interfaces.  

public interface IAppConfigurationElement
{
  string Name { get; set; }
  string DateTimeFormat { get; set; }
  string LanguageDefault { get; set; }
  double TimeZoneOffset { get; set; }
}

Esta interfaz define los parámetros generales de mi aplicación. En la siguiente interfaz, combinamos estos parámetros de configuración con la interfaz de IoC.

public interface IAppConfigurationSection
{
  IAppConfigurationElement Parameters { get; set; }
  IContainerConfiguration Ioc { get; set; }
} 

Finalmente combinamos las interfaces que darán a nuestra aplicación los parámetros que hemos definido y el Framework de IoC que usaremos

public interface IGlobalSettings
{
  IContainer Ioc { get; }
  IAppConfigurationElement Parameters { get; }
}

Con esto mejor cerramos el artículo de hoy, creo que me he pasado de largo  así que dejamos la implementación y los test para otro día…

 Hasta la próxima...

DDD: 1- Introducción a un esquema genérico…

Me ha costado trabajo decidirme, hay tantos ejemplos de aplicaciones con arquitectura DDD publicados en internet en el que cada uno desarrolla un esquema distinto que uno se piensa una y otra vez si lo que está haciendo estará bien o será un simple disparate.

Partiendo de esta duda, el objetivo de esta serie no es crear una guía para orquestar una arquitectura DDD, ni siquiera pretendo que sea un modelo a seguir. Mi objetivo es más bien ir compartiendo por aquí las cosas que se me van ocurriendo y de ser posible, generar un debate que nos ayude a todos a tener puntos de vista diferentes.

Sin más, empiezo por donde se empieza cualquier arquitectura  El diagrama de capas:

Esta parte es la que casi siempre tengo clara… La distribución de las capas en Dominio, Aplicación, Infraestructura, la capa de servicios WCF (opcional) y las interfaces de usuario, cada una con su flujo de información.

No quiero entrar a analizar qué va dentro de cada capa porque precisamente la idea es ir comentando el desarrollo que vayamos realizando paso a paso. Solo aclarar que en muchas arquitecturas DDD, puede existir un flujo de información entre la interfaz de usuario y el dominio.  Este flujo se ve en muchas arquitecturas que muestran inyección de dependencia de los repositorios dentro de los controladores de un proyecto MVC (incluso ASP.NET MVC está preparado para inyectar dependencias a los controladores). En este caso, no vamos a tener ese flujo y es por eso que no lo represento.

¿Por qué? Hoy en día es poco habitual que desarrollemos una sola aplicación, normalmente nuestros proyectos requieren que para un mismo dominio tengamos varios frentes por el que lo atacamos (UI para móviles, UI para desktop, servicios que expongan funcionalidad a terceros, etc.). Con el objetivo de centralizar la lógica de aplicación (servicios en la capa aplicación) y permitir la reutilización de código, es que ninguna interfaz de usuario llega al dominio si no es mediante la capa de aplicación.

En Visual Studio cada capa está definida como un “Solution Folder”, por lo que la estructura de mi arquitectura queda más o menos así…

Creo que se ve que existen 12 proyectos dentro de la solución, por lo que el desarrollo va mucho más adelantado que esta serie de artículos. Espero a medida de que el tiempo me lo permita, ir poniéndome al día…  pero sobre todo, espero que se diviertan tanto como yo...

Salu2

Es la hora del cambio…

Primero que todo disculparme si alguien entra en este post pensando que voy a hablar de política :P siento que no sea así. Ya me sobra con el regaño que me dieron ayer por decir que “insidiar” era un verbo. ;)

Entrando en la materia que nos ocupa… Muchas veces cuando escuchamos hablar de arquitecturas del tipo DDD, TDD o N capas orientadas al dominio pensamos que todo eso es cosa de unos cuantos frikis que se pasan el día sin nada que hacer e intentando complicarnos la vida y, nada más lejos de la realidad. La arquitectura de un proyecto puede muchas veces llevarnos a escribir un mal código.

Ayer a un colega le pasó algo curioso respecto a eso. Introducir una arquitectura orientada al dominio en un grupo de trabajo con apenas experiencia es complicado, la curva de aprendizaje cuando se parte de cero es realmente alta y son muchos los conceptos y paradigmas que nos vemos obligados a cambiar. Entidades, DTO, Inversión de control, Inyección de dependencias, etc… todo esto puede ocasionar un retraso en el proyecto que nadie está de acuerdo en asumir.

Para evitar todo esto, diseñó una arquitectura N capas de toda la vida con posibilidades de dividirla en niveles, pero a su vez fue insertando conceptos como: Dominio, entidades, DTO, capas, niveles, servicios del dominio, repositorios, etc. toda una base que le permitiera en un momento dado, dar el cambio definitivo a arquitecturas verdaderamente orientadas al dominio.

Ayer se le presentó una problemática, necesitaba mandar a encender desde un panel de administración un conjunto de dispositivos por un tiempo determinado. Ya tenía funcionando toda la lógica de encendido y solo debía insertar el nuevo requerimiento de definir el tiempo que dicho dispositivo iba a permanecer encendido.  La secuencia para encender dispositivos era la siguiente:

Con el nuevo requerimiento la secuencia quedó de la siguiente manera:

La solución dada no me gustó porque rompe con la naturaleza propia del método, se está actualizando estados en un método destinado a seleccionar. Esto evita que dicho método pueda ser reutilizado para lo que fue pensado, traer un listado de dispositivos.

Cuando le dije cómo lo hubiera hecho yo, el diagrama de secuencia quedó de la siguiente forma:

Ummm… ¿Qué pasa aquí? Yo viajo al dominio mediante los servicios WCF dos veces para realizar una acción. Al final, él pensó una solución que desde el punto de vista de arquitectura está mal, pero es mucho más eficiente que la mía.

¿Por qué nos pasa esto? Si miramos el último diagrama de secuencia vemos como si algo faltara en la arquitectura que permita hacerlo bien y además que sea eficiente. Si me llevo esto a DDD ¿cómo queda?

Diagrama de secuencia:

Feliz y contento… toda la lógica que estaba en el UI ahora pasa a mi capa de aplicación, por lo que solo viajaría una vez por la capa de servicios WCF y todo lo que está dentro del ApplicationLayer, podría ser reutilizado desde otros UI.

Nada, que llegamos a la conclusión que… es la hora del cambio J

Salu2

El Daily Stand-Ups (Scrum) ¿Insuficiente?

En el proyecto en el que me encuentro actualmente (equipo de 4 personas) hemos logrado poner en práctica toda la teoría conocida sobre SCRUM. Algunas aplicadas 100% según la documentación, otras, adaptadas a los requerimientos del proyecto en sí.

Esto no es nuevo, todos sabemos que la guía para el desarrollo ágil existe, podemos aprender y usar de ella todo lo que enseña, pero al final… cada proyecto es un libro aparte que se escribe a su forma y bajo sus propios requerimientos.

Uno de los puntos que no puede faltar (adaptado o no) en un desarrollo ágil es el Daily Stand-Ups. Esas reuniones de 15 minutos en las que intercambiamos qué hacemos, qué hemos hecho y qué problemas tenemos.

Este tipo de reunión está definida en el desarrollo SCRUM de la siguiente manera:

Daily Stand-Ups (Scrums)

During a sprint, the team, the ScrumMaster, and the product owner (mejor no invitarle a todas :P ) commit to meeting once daily in the same place and at the same time to discuss any issues that are preventing work from being done. Meetings are held with everyone standing and time boxed to no longer than 15 minutes. Anyone interested is invited to attend these meetings; however, only the people classified as Pigs are allowed to speak at these meetings.

 At the meeting, each team member answers the following three questions:

• What have you done since yesterday?
• What are you planning to do today?
• Do you have any problems preventing you from accomplishing your goal? What progress has been made on existing impediments? Can the blockage be removed or must it be escalated? (The ScrumMaster looks after this area.)

La aplicación de este tipo de reuniones dentro de un proyecto crea un entorno de trabajo sumamente favorable. Todos conocemos qué ha hecho o qué está haciendo cada miembro del equipo, todos aportamos solución a los posibles problemas y todos estamos capacitados en un momento dado de asumir una tarea determinada. Los cuellos de botella en un entorno así, son detectados muy pronto y permite a su vez, darle una pronta solución.

A grandes rasgos, el problema sobre qué hace cada miembro del equipo estaba resuelto. Todos éramos capaces, sin pérdida alguna de tiempo, de asumir o colaborar con la tarea de otro. Pero… (Grrrrrr!!!... siempre hay peros)

Nos dimos cuenta que algo más detallado se nos estaba escapando. Cada tarea asignada a un miembro del equipo normalmente está compuesta por Bugs, Tasks, o Issues. La solución a nivel de código que se daba a cada elemento muchas veces no contaba con la calidad suficiente, o simplemente no se aplicaba una solución que pudiera ser reutilizable. A este nivel de detalle en los Daily Stand-ups, no llegábamos.

Una primera solución fue enviarnos un correo al final del día en el que cada uno contábamos  qué había hecho (a nivel de Bugs, Tasks o Issues) hablando un poco de la solución implementada en cada caso, pero ( y más peros…) Somos informáticos, odiamos trabajar de más :D  y, escribir este correo a final del día iba a terminar perdiéndose. 

Pensando un poco en el correo y la información que recogíamos nos dimos cuenta que esto al final era lo mismo que mirar toda la actividad realizada durante el día en el TFS (Team Fundation Server) ¿Por qué entonces no preguntarle al TFS lo que cada miembro del equipo había hecho durante el día? Incluso, ¿Por qué no preguntarle al TFS lo que había hecho por sí solo durante el día? (Builds de integración continua fallidos, Works Items creados, etc.)

Si pudiéramos tener acceso al TFS desde internet, la solución hubiera sido más simple, pero en la mayoría de los casos esto no es así. Al final, desarrollamos una tarea que recoge toda la información del TFS realizada en el día y nos envía un resumen por correo :)

La solución nos pareció interesante y por si pudiera ser reutilizada por alguien más, la publicaremos acá en cuanto le apliquemos un poco de Refactoring y le pongamos una cara bonita.

Evento de ADO.NET con SNUG

Hola a todos...

El martes 20 de septiembre, que es el martes próximo (mañana no, el próximo… o sea… la semana que viene… en fin, que me lío) :-p, daré un evento con los chicos de SNUG sobre ADO.NET

De ADO.NET hay mucha información, libros, eventos, blogs en Internet que contienen material excelente sobre toda la arquitectura, clases, métodos, propiedades y eventos que lo componen.

Para no hacer de este evento uno más de esos tantos, nos vamos a centrar en las buenas prácticas ¿qué debemos y qué no debemos hacer cuando usamos ADO.NET? Esto no quiere decir que no expliquemos su arquitectura o no vayamos a contar qué es un Command, Connection o DataReader, solo que no nos quedaremos ahí, sino que profundizaremos con ejemplos (Visual Studio 2010 + C#) cómo poner en un proyecto real toda esa información.

Espero verlos ahí, y que aprendamos que no solo usando la última moda como Entity Framework, Linq2Sql o NHibernate, podemos tener buenas prácticas en nuestros desarrollos.

La URL de registro para el evento es esta: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032493902&Culture=es-ES

Nos vemos ;)