IDisposable Thoughts

Desde hace varios días hay una thread muy interesante acerca de separación de responsabilidades, repositorio, validación y otras hierbas en la lista de correo d Alt.Net Hispano, antes de continuar, les recomiendo una merecida lectura.

El punto expuesto por José Romaniello y que a su vez toma como base las enseñanzas de Fabio Maulo no puede estar más cargado de razón. Anteriormente como menciona Carlos Peix, cuando Fowler y Eric Evans en su libro DDD definieron Repository no existía el concepto de IQueryable y creo que no muchos se lo veían venir, así que simplemente si asociamos que Repository es una abstración superior del acceso a datos y este se debe comportar como una colección en memoria (mezclando las definiciones de Fowler y Evans) y coincidimos en que en la .Net Framework las colecciones pueden extenderse a IQueryable, es fácil razonar que por definición un repositorio finaliza implementando IQueryable<T> (mera jalada mi filosofía y asociación, pero para filósofo preguntémosle mejor a @ajlopez!)

Bien, sin embargo exponer IQueryable<T> directamente tiene un par de problemas e implicaciones, principalmente relacionados con la semántica de la colección y el acceso a ella. Estoy desacuerdo que la definición o diferencia entre dao y repository es cada vez más difusa, de hecho, comparto la visión de usar un Dao y exponer el acceso a los datos a través de ella, ahora bien, la pregunta del millón se traduce en la siguiente, cómo debe lucir mi Dao? Quizás algo similar a como lo expone Fabio y José:

public interface IDao<T> {
    IQueryable<T> Retrieve(Expression<Func<T, bool>> predicate);
    IQueryable<T> Count(Expression<Func<T, bool>> predicate);
}

¿Un momento, porqué exponer IQueryable<T> y no IEnumerable<T>? O sea, no estoy dándole a mis consumidores demasiado poder en lo que pueden lograr o hacer?

En el punto de exponer IQueryable<T> y IEnumerable<T> y así evitar problemas posteriores tiene defensores y enemigos por todos lados. Personalmente estoy deacuerdo con exponer IQueryable<T> en el repositorio e inclusive exponer un método para facilitarte el query de los elementos (y no hacerlo “directamente” usando una consulta LINQ inline). Verás, el meollo de todo es evitar andar abriendo clases como si fueramos cirujanos.

Si exponemos métodos como “GetUserById(5)” y este a su vez expone IEnumerable<T> esta bien (para ese uso en *específico*) pero recordemos que por lo general un repositorio será expuesto para múltiples usos (o sea, no solamente para obtener usuarios con ese Id, ¿qué tal si luego quieres obtener la lista de usuarios? ¿y si quieres filtrarla?, ni hablemos del problema eterno del pagineo…

Bien, he aquí cuando se nota la utilidad de la separación de concerns de presentación con todo lo demás, por ejemplo, recordemos que el Controller es un _concern de presentación_ así mismo como es la vista (si, señores, como vengo dicíendolo por mucho tiempo, el controller *no es* la lógica del negocio, simplemente es la lógica del presentador).

Ok, llevemos esto más allá, es probable que tengamos “casos de uso” de lógica relacionada a la presentación, no a la del negocio, por ejemplo, el típico concern de búsqueda de elementos, las opciones de búsqueda, filtrado, son conerns meramente de la lógica relacionada a la presentación, eso involucra entonces que debemos permitir que nuestro controller (o presenter, dependiendo del patrón de presentación usado) directamente actúe contra la dao? muchos proponentes dicen que no debe ser así (y ellos mismos hasta se contradicen si los estudian detenidamente). Más de alguien me contestará que simplemente realizar la consulta mediante Specification es suficiente (pueden tomar como ejemplo el proyecto de mi amigo Romaniello pero a mi criterio seguimos exponiendo IQueryable hacia la vista final, algo que a mi concepto no me agrada para nada.

Es ahí cuando entra en acción el concepto de Application Services (no confundir con Domain Services), un Application Service se encarga de verselas contra el mundo “externo” ajeno al dominio (entiendase, lo que el mundo externo consumirá del dominio) mientras que el Domain Service vela por la coordinación de operaciones dentro del dominio. Simple [Jimmy Bogard tiene un excelente artículo al respecto, se los recomiendo]

Digamos entonces que tenemos algo simple y sencillo, nuestra interface de búsqueda del servicio de búsqueda que utiliza nuestro controller

interface SearchService {
    IEnumerable<ItemResult> SearchItems(SearchParameters parameters);
}

Como veran se expone la mínima interface necesaria para ver los elementos finales de la búsqueda (en este caso una colección simplemente necesita IEnumerable<T>, de hecho, es probable que el elemento retornado no tenga nada que ver con la entidad consultada dentro del servicio usando un repositorio (de hecho podría ser que tengamos que consultar varias entidades y hacer varios cambios antes de retornar la entidad). ¿Qué pasa entonces con conceptos como pagineo y/o límites? como vemos IEnumerable<T> no expone conceptos como Count (y menos otros como TotalCount o Limit-Offset), porqué entonces no aprovechamos que ahora hablamos de un concepto totalmente diferente y que involucra solamente presentación, que tal si retornamos IPageable<T> ?

interface IPageable<T> : IEnumerable<T> {
    int TotalCount { get; }
    int Limit { get; }
    int Offset { get; }
    int Max { get; }
}

En resumidas cuentas, hacer que el repositorio sea flexible funciona, pero no debemos permitir permear conceptos de dominio y mezclarlos con conceptos de presentación, no vaya a ser que terminemos al final con un super repositorio con 50 métodos.

Como siempre comentarios al respecto, soy todo oídos (u ojos, whatever!) ¡Hasta luego!