IQueryable y repositorys: ¿tomar 2?

Debo admitir que llevo el letrero “Repository should not return IQueryable” porque es más difícil de probar. Me han influenciado las respuestas a otras preguntas como esta y esta .

Esta mañana he estado leyendo el blog de ScuttGu sobre ASP.NET vNext, donde detalla la vinculación de modelos utilizando un método Select que parece depender de IQueryable para paginación y clasificación.

¿Crees que esto nos obligará a reconsiderar el papel que juega IQueryable en los repositorys?

El repository DDD debe encapsular los aspectos técnicos del acceso a los datos:

Definición: Un repository es un mecanismo para encapsular el almacenamiento, la recuperación y el comportamiento de búsqueda que emula una colección de objetos.

También es responsable de manejar el medio y el final de la vida de los objetos de dominio. La interfaz del repository pertenece al dominio y debe basarse en el lenguaje ubicuo tanto como sea posible. Además del libro DDD, estos dos artículos cubren casi todo lo que necesita saber al diseñar repositorys:

  • Cómo escribir un repository
  • El repository genérico

La exposición de IQueryable en la interfaz del repository no es óptima en mi opinión. IQueryable no es parte de Ubiquitous Language. Es un tecnicismo, no tiene un significado de dominio. En lugar de encapsular la recuperación de datos, el Repositorio expondría el mecanismo de acceso a los datos desnudos, lo que esencialmente frustra el propósito de tener un Repositorio en primer lugar.

En cuanto a ASP.NET. Este es un marco de UI. ¿Por qué permitiría que el marco de la interfaz de usuario afectara el diseño de su modelo de dominio? Los ejemplos de Microsoft a menudo fomentan cosas como la cuadrícula de datos de UI enlazada directamente a las tablas de su base de datos. O, más recientemente, los controles vinculados a lo que se conoce como Modelo de dominio, mientras que de hecho es un Modelo anémico o simplemente un contenedor de datos tonto con get / sets. La cita del artículo que mencionas (puse un poco de énfasis):

El enlace modelo es un enfoque centrado en el código para el enlace de datos . Le permite escribir métodos de ayuda de CRUD dentro del archivo de código subyacente de su página, y luego fácilmente conectarlos a cualquier control de servidor dentro de la página. Los controles del servidor se encargarán de llamar a los métodos en el momento apropiado en el ciclo de vida de la página y vincular los datos a los datos .

Mi interpretación de esto es eliminar el modelo y los objetos, y simplemente unir sus datos a la IU. Este es probablemente un enfoque válido y justificado en muchos casos. Pero dado que la pregunta fue etiquetada como DDD, diría que en DDD esto se llama Smart UI Anti-Pattern .