Después de ver la flexibilidad del repositorio genérico, quejarme de eso, hablar del repositorio concreto, y ver que todavía hay cosas que no me gustan, llega el momento de otra alternativa.

El no-repositorio

Según la biblia del DDD, las responsabilidades que debe asumir un repositorio son, entre otras:

• Simular una colección en memoria a la que podemos añadir o quitar objetos.
• Permitir seleccionar un conjunto de objetos a partir de distintos criterios.
• Devolver objetos completamente instanciados encapsulando la tecnología real de almacenamiento y consulta.

Pues es curioso, pero si estás usando un ORM seguro que ya tienes algo parecido. En el caso de NHibernate, es el objeto ISession y si es Entity Framework… mejor que te lo explique Unai con sus pros y sus contras, que yo de EF no sé mucho.

Los que defienden esta idea ponen como ventajas:

• Simplifica la arquitectura de la aplicación, eliminado una capa que, desde su punto de vista, no aporta nada (los repositorios).
• Permite una gran flexibilidad a la hora de realizar consultas, pudiendo seleccionar caso por caso los datos a cargar y las relaciones a navegar (en tanto en cuanto lo permita el ORM). Esto soluciona uno de los problemas que de momento no habíamos solucionado con las implementaciones anteriores.
• Permite sacar el máximo partido al ORM. El argumento es similar al de no abstraigas el contenedor de IoC, pero en este caso no me convence porque el contenedor no lo veo en ningún sitio de la aplicación, y con este sistema el ORM sí que lo veo (y por todas partes).

Algunos detractores de este estilo dicen que al no abstraer el ORM no vas a poder cambiarlo pero, seamos serios, ¿cuántas veces se cambia de ORM? Además, el ORM influye mucho más en la aplicación de lo que pueda parecer en un principio, así que por muchos repositorios que tengas, si cambias de ORM seguramente tengas que hacer bastantes ajustes de todas formas.

Un buen complemento de esta técnica son lo que Fabio llama Enhanced Query Objects, que no son más que una forma de encapsular consultas de forma individual para cada caso de uso que encontremos en la aplicación. Algo parecido se puede hacer con especificaciones, al estilo de Microsoft N-Layered (aunque en ese ejemplo se estén usando con repositorios genéricos).

Para mi, el mayor inconveniente que tiene este tipo de no-repositorio es el mismo que le veía al repositorio genérico: expone demasiada funcionalidad hacia las capas superiores de la aplicación. Acotar lo que se puede hacer siempre me ha parecido una buena idea porque acaba simplificando la implementación y ayuda a saber qué operaciones están disponibles.

El uso de Enhanced Query Objects o especificaciones ayuda a mitigar un poco este problema porque es más sencillo localizar lo que se puede hacer, pero sigue quedando todo demasiado abierto. Hay que tener en cuenta que además de las responsabilidades que enumeraba más arriba, el repositorio cumple una misión fundamental: actúa como contrato entre dos áreas de la aplicación, el dominio y la persistencia. Con esta implementación el contrato desaparece, al menos de forma explícita.

No obstante, como dice Unai en su post, todo se reduce a una cuestión de ser consciente de lo que te puede aportar y lo que sacrificas por el camino.

Ya casi he terminado mi repaso por distintos tipos de repositorios y todavía no he dicho cual es (ahora mismo) la opción que más me gusta. Eso lo dejo para el último post de la serie :-)