¿Puedo usar esto en el modelo de repositorio?

Question

Estoy trabajando en un proyecto usando ASP.NET MVC y el modelo de repositorio. Tengo clases de repositorio y servicios que consumen estas clases de repositorio. Mi pregunta es: ¿es correcto devolver un IQueryable desde mi clase de repositorio y luego usar " .Where " y " .OrderBy " en un servicio para generar una lista? En caso afirmativo, ¿es la mejor práctica?

¡Gracias!

Answer 1

Para empezar: no hay "correcto" o "incorrecto" aquí. Es solo una cuestión de lo que funciona mejor para usted y el sistema que está creando. Por ejemplo, Rob Conery hizo una aplicación de muestra de ASP.NET llamada Storefront con exactamente el patrón que está describiendo e inició una gran guerra de llamas. Una gran parte de la discusión evolucionó alrededor del patrón del Repositorio que se considera el "original". según lo descrito por Eric Evans en su libro Diseño controlado por dominio y que describe la interfaz de un repositorio como uno que acepta y / o devuelve instancias reales (de listas de instancias) y no alguna interfaz de consulta.

Demasiado para la teoría. ¿Qué elegir para su sistema? La razón por la que no elegiría directamente la ruta IQueryable es que realmente filtra un poco de mi estrategia de persistencia a la capa del cliente (en este caso, la capa de servicio). Dado que tiene sentido principalmente devolver un IQueryable si está recuperando objetos de la base de datos usando LINQ a [un método de acceso a la base de datos (como SQL, Entidades, ...)]. Solo entonces .Where u .OrderBy estarán optimizando el resultado de su consulta. Obviamente, no tiene sentido si está utilizando un código de código de acceso a la base de datos que obtiene una lista completa que luego expone del Repositorio usando LINQ to Objects. En resumen: vincula su capa de cliente con la estrategia de acceso a la base de datos basada en LINQ que está utilizando.

Siendo un poco purista, preferiría no sacar a la superficie este vínculo con LINQ de mi repositorio, y elegiría ofrecer criterios de dónde y ordenar a través de los parámetros de las operaciones del repositorio. Puedo hacer toda la optimización de recuperación en el repositorio y devolver un conjunto limpio y limpio de objetos de dominio.

Así que al final todo se reduce a: lo que sea mejor para ti está bien.

Answer 2

No veo por qué eso sería un problema. Si va a ser más específico en los datos que recuperará en su capa de servicio, eso significa que se transfieren menos datos entre la aplicación y la base de datos, lo que significa una mayor eficiencia. Al hacerlo, también implementará una carga diferida u obtendrá los datos cuando los necesite. Teniendo en cuenta la apatridia de la web, esto es algo bueno. No desea recuperar todos los datos en caso de que pueda usarlos.

En otras palabras, no tiene sentido obtener la lista completa de usuarios, simplemente seleccionar el que se llama "Jackolantern".

La mejor manera de pensarlo es así: si decide cambiar de MSSQL a MySQL mañana, ¿tendrá que replicar la lógica de negocios? Si es así, entonces está utilizando su repositorio incorrectamente.

Answer 3

Sí, estoy bastante contento con el repositorio que devuelve IQueryable, pero con una advertencia: algunas funciones de Linq no están disponibles en todos los proveedores. Por ejemplo, los métodos Single / SingleOrDefault no están disponibles en Linq to Entities. Por lo tanto, es posible que su capa de servicio tenga que saltar algunos aros según la implementación concreta de su repositorio.

Normalmente pongo la interfaz de las clases de repositorio en la capa de dominio y las implementaciones reales en la capa de servicio.