He estado buscando durante bastante tiempo una buena solución a los problemas presentados por el patrón típico del Repositorio (lista creciente de métodos para consultas especializadas, etc. ver:http://ayende.com/blog/3955/repository-is-the-new-singleton).

Realmente me gusta la idea de usar consultas de comando, particularmente a través del uso del patrón de especificación. Sin embargo, mi problema con la especificación es que solo se relaciona con los criterios de las selecciones simples (básicamente, la cláusula where) y no trata los otros problemas de las consultas, como la unión, agrupación, selección de subconjuntos o proyección, etc. Básicamente, todos los aros adicionales que deben atravesar muchas consultas para obtener el conjunto de datos correcto.

(nota: uso el término "comando" como en el patrón Comando, también conocido como objetos de consulta. No estoy hablando de comando como en la separación comando / consulta donde hay una distinción entre consultas y comandos (actualizar, eliminar, insertar))

Así que estoy buscando alternativas que encapsulen toda la consulta, pero que sean lo suficientemente flexibles como para que no solo cambies los Repositorios de espaguetis por una explosión de clases de comando.

He utilizado, por ejemplo, Linqspecs, y si bien encuentro algo de valor en poder asignar nombres significativos a los criterios de selección, simplemente no es suficiente. Quizás estoy buscando una solución combinada que combine múltiples enfoques.

Estoy buscando soluciones que otros puedan haber desarrollado para solucionar este problema, o abordar un problema diferente pero que aún satisfaga estos requisitos. En el artículo vinculado, Ayende sugiere usar el contexto nHibernate directamente, pero creo que eso complica en gran medida su capa de negocios porque ahora también tiene que contener información de consulta.

Ofreceré una recompensa por esto, tan pronto como transcurra el período de espera. Así que, por favor, haga que sus soluciones sean dignas de recompensa, con buenas explicaciones y seleccionaré la mejor solución y promocionaré a los finalistas.

NOTA: Estoy buscando algo que está basado en ORM. No tiene que ser EF o nHibernar explícitamente, pero esos son los más comunes y se adaptarían a los mejores. Si se puede adaptar fácilmente a otros ORM, sería una ventaja. Linq compatible también sería bueno.

ACTUALIZACIÓN: Estoy realmente sorprendido de que no haya muchas sugerencias buenas aquí. Parece que las personas son totalmente CQRS, o están completamente en el campo del Repositorio. La mayoría de mis aplicaciones no son lo suficientemente complejas como para garantizar CQRS (algo con lo que la mayoría de los defensores de CQRS dicen fácilmente que no debería usarlo).

ACTUALIZACIÓN: Parece que hay un poco de confusión aquí. No estoy buscando una nueva tecnología de acceso a datos, sino una interfaz razonablemente bien diseñada entre la empresa y los datos.

Idealmente, lo que estoy buscando es algún tipo de cruce entre los objetos de consulta, el patrón de especificación y el repositorio. Como dije anteriormente, el patrón de especificación solo trata con el aspecto de la cláusula where, y no con los otros aspectos de la consulta, como uniones, subselecciones, etc. Los repositorios tratan con toda la consulta, pero se van de las manos después de un tiempo . Los objetos de consulta también se ocupan de toda la consulta, pero no quiero simplemente reemplazar los repositorios con explosiones de objetos de consulta.