Tras quejarme del repositorio genérico, del repositorio concreto y del no-repositorio, ya empiezo a estar un poco cansado. Ha llegado el momento de ver cómo me gustan a mi los repositorios (ahora).

La parte transaccional

Para mi, el repositorio ideal es así:

public interface IProductRepository
{
   Product FindById(Guid id);
}

Ya está. Si pudiera tener todos mis repositorios así, con un único FindById, sería genial porque querría decir que he conseguido crear un modelo rico, enlazado y definido que me permite ejecutar todas las operaciones a partir del aggregate root que las va a realizar. En todo caso, no me parece mal tener otros FindByXXX que permitan buscar por alguna clave natural.

¿Y para añadir nuevas entidades? Intento nunca crear nuevos aggregate roots. Si puedo, hago que la creación de entidades se realiza a partir de otras entidades para aplicar así persistencia por alcance. Hay veces que no me queda más remedio y en ese caso añado un método void Add() al repositorio. Además el nombre es ese, Add, para reforzar la idea de que estoy añadiendo una cosa nueva, no actualizando una que ya existe. De hecho, si el ORM lo permite, prefiero que ese método lance una excepción si se intenta guardar una entidad que no sea transient.

¿Y para actualizar entidades que han sido modificadas en memoria? Eso no te hace falta. Si estás usando un ORM de verdad, su implementación interna del patrón UoW junto con su sistema de seguimiento de cambios (change tracking) ya se encargarán de almacenar los cambios que hayas hecho en las entidades que cargadas dentro de ese UoW cuando hagas el commit del UoW. Pero, ¿qué pasa con las entidades desconectadas del UoW? No deberías tener entidades desconectadas del UoW. Nunca. Cuando lleguemos a la segunda parte del post y veamos como se hacen las lecturas, esto quedará más claro.

¿Y el borrado de entidades? Antes que nada habría que preguntarse si realmente tiene sentido borrar entidades. Si después de pensarlo mucho hace falta borrarlas, acabo añadiendo el método void Delete(Entity entity) al repositorio.

Con todo esto, en el peor de los casos acabaríamos con un repositorio así:

public interface IProductRepository
{
    // Este método está siempre
    Product FindById(Guid id);

    // Este puede ser necesario: búsqueda de UNA entidad 
    // usando una clave natural
    Product FindByBarcode(string barcode);

    // Este método hay que intentar evitarlo usando
    // persistencia por alcance
    void Add(Product product);

    // Antes de añadir este método, hay que responder la
    // pregunta: ¿realmente tiene sentido borrar esta entidad?
    void Delete(Product product);
}

Una de las cosas que más me gustan de este repositorio es que minimiza la contaminación del dominio de la que me quejaba en posts anteriores. Tener que plantearse si realmente son necesarios los métodos Add/Delete también ayuda a pensar más a fondo sobre el dominio que estamos modelando y tratar de descubrir alternativas a la hora de modelarlo.

La parte de lectura

El repositorio que acabamos de ver se encarga únicamente de la parte OLTP de la aplicación. Es decir, nos sirve para cargar una entidad cuyo ID ya conocemos (o alguna clave natural) y ejecutar acciones sobre ella. Por suerte o por desgracia, para implementar la mayoría de aplicaciones necesitamos exponer información hacia el exterior, ya sea en forma de interfaz de usuario o de servicios interoperables por otros sistemas, y para eso suele ser necesario leer más de una entidad a la vez.

A la hora de leer los datos es fundamental tener en cuenta es el uso que le vamos a dar. Es algo de lo que me he ido quejando con las anteriores implementaciones de repositorio, y es que si hace falta cargar entidades completas para luego convertirlas a DTOs o Models, podemos acabar teniendo problema de eficiencia.

La solución que me gusta es leer directamente de la base de datos los DTOs o los Models. Para ello se pueden usar varias alternativas, como escribir sentencias sql a mano o usar un Micro ORM, ahora que están tan de moda.

Personalmente, si puedo, aprovecho las posibilidades del ORM que suelo usar, NHibernate. NHibernate permite utilizar proyecciones para realizar consultas específicas en las que, por ejemplo, sólo estamos interesados en cargar parte de una entidad o queremos realizar algún cálculo en la base de datos (por ejemplo, un sum o un max). Estas proyecciones se pueden hacer con cualquiera de los mecanismos de consulta de NHibernate: HQL, Linq, Criteria, QueryOver o incluso SQL nativo. La ventaja es que la mayoría de las veces es fácil apañarse con Linq, con lo que la cosa queda muy legible:

var products = session.Query<Product>()
                      .Where(x => x.AvailableInStock)
                      .Select(x => new ProductDTO
                      {
                          Id = x.Id,
                          Name = x.Name,
                          Family = x.Family.Name,
                      }).ToArray();

La ventaja de esto es que permite lanzar cada consulta de la manera más eficiente posible y tratarlos como lo que son, casos de uso individuales y específicos. Puesto que estas lecturas devuelven DTOs o Models, está claro que el interface de estos servicios de lectura de datos no pertenece al dominio de la aplicación. Estos servicios como parte de la infraestructura y se tratan como tales.

Una ventaja inmediata de esta arquitectura es que desaparece la capa de mappers que suele existir para convertir de entidades a objetos que se exponen hacia el exterior, ya sean DTOs para comunicaciones o Models para las vistas.

Es importante ser disciplinado y mantener cada DTO/Model para un caso de uso concreto y con la granularidad adecuada. En el caso ideal, cada vista de la aplicación o cada servicio expuesto hacia el exterior debería poder cargarse en una sola consulta de BD, aunque esto no siempre es posible. Si empezamos a reutilizar DTOs en distintos casos de uso, acabamos por tener objetos demasiado grandes que son complicados de cargar desde la base de datos. Mi opinión ahí es clara: si el DTO que existe no te sirve, no luches mucho por modificarlo para cubrir 2 casos, crea un segundo DTO. Esto permite mantener las consultas optimizadas y focalizadas.

Ahora ya queda claro porque no existe un método Update en el repositorio. Las entidades nunca viajan hasta la capa de presentación o servicios externos y, por tanto, nunca vamos a tener entidades desconectadas del UoW.

Algunas consideraciones finales

Esto NO es CQRS. Según los expertos en el tema, si no hay modelos de datos separados de lectura y escritura no se puede considerar CQRS. En este caso estamos usando LA MISMA base de datos para ambas cosas.

La primera vez que leí sobre este tipo de arquitectura fue en este post de Greg Young, que acabó convirtiéndose en el germen de lo que luego evolucionarían entre él y Udi Dahan hasta convertirlo en CQRS. Tal vez yo simplemente sea más lento y dentro de un tiempo me dé cuenta de que esto no sirve y llegue a la conclusión de que la solución es CQRS. Ya veremos.