Patrón de repositorio - Escaparate MVC

Question

He estado mirando la tienda MVC y veo que IQueryable se devuelve desde las clases de repositorio. Si se pregunta si no está utilizando LINQ, ¿tiene sentido devolver ese objeto? En el caso de LINQ, tiene sentido debido a la ejecución diferida, por lo que tiene sentido agregar filtros en la capa de servicio, pero si no utiliza LINQ, debería filtrar la BD en muchos casos. En este caso, ¿acabo de agregar métodos que hacen el filtrado al repositorio? Si lo hago, ¿la capa de servicio es realmente útil?

Answer 1

Los argumentos se pueden hacer de cualquier manera, ver este reciente entrada de blog: Should my repository expose IQueryable?

Answer 2

El material IQueryable que Rob Conery puso en el escaparate MVC es innovadora, pero de ninguna manera es la norma cuando se trata de crear repositorios. Generalmente, un repositorio es responsable de mapear su dominio hacia y desde la base de datos. Devolver IQueryable realmente no realiza ninguna asignación y depende de la capa de servicios para hacer eso. Esto tiene sus ventajas y desventajas, pero basta decir que no es la única forma de hacerlo.

Notarás, sin embargo, que tus servicios terminan siendo un poco apestoso debido a todo el código duplicado. Por ejemplo, si solo desea obtener una lista de todos los usuarios en su base de datos, deberá definir esa función tanto en el repositorio como en la capa de servicio. Sin embargo, donde brilla la capa de servicio es cuando se necesitan múltiples transacciones a/desde la base de datos para una operación.

Answer 3

El problema que tengo al exponer IQueryable a la capa de servicio es que si alguna vez deseaba envolver la capa de repositorio detrás de un servicio web sin romper el código de capa de servicio no podría hacerlo sin usar ADO.NET Data Services pero luego El código del repositorio sería esencialmente redundante.

Aunque creo que puede ser bastante productivo para aplicaciones pequeñas, cuando comienzas a mirar la escala y la distribución hace más mal que bien.