ASP MVC: ¿Deberían los servicios devolver IQueryable's?

Question

¿Qué opinas? ¿Debería tu DAO devolver un IQueryable para usarlo en tus controladores?

Answer 1

Por el momento, suena atractivo, pero really isn't.

Answer 2

No. Sus controladores no deben manejar ninguna lógica compleja en absoluto. Mantenlos delgados; el Modelo (no DAO) debe devolver al Controlador todo lo que necesita para pasar a la Vista.

Ver consultas (o incluso consultas) en una clase de controlador es algo que consideraría un olor a código.

Answer 3

Si sigue el paradigma de "modelos de grasa, controladores delgados", entonces no.

Ver este artículo en el Fat Controller anti-pattern.

Answer 4

Me encanta pasar IQueryable en mis controladores porque no tengo que crear métodos de paginación y clasificación cojos en cada método DAO e interfaz a lo largo de la vida útil del desarrollo de mis aplicaciones.

GetCustomersByLastname(string lastname) 

se convierte rápidamente en

GetCustomersByLastname(string lastname, string sortcolumn, int pagesize, int page) 

Una y otra vez y otra vez y otra vez. ¡Bleck!

Con IQueryable puede implementar la paginación y la ordenación de forma ortogonal, como aprovechar el proyecto IPagedList. La devolución de IQueryable también le brinda acceso fácil al objeto total .Count() sin más perversión de su capa de datos.

@Robert s argumento de IQueryable es igual a los controladores de grasa es muy inestable. Un controlador de grasa sería similar a las páginas hinchadas .aspx.cs de antaño. Si todo lo que hace es conectarse a su DAL y luego enviar los resultados de su no ganar "gordura" de su técnica de consulta, lo obtiene de meter mucha lógica dentro de una sola clase. Usted no obtiene un Controlador de Grasa debido a sus métodos de acceso a los datos, a menos que empiece a rodar el registro, las notificaciones y otras preocupaciones ortogonales dentro.

public ActionResult Detail(string searchTerm) 
{ 
    var model = MyDAL.MyObjects(searchTerm); 
} 

vs:

public ActionResult Detail(string searchTerm) 
{ 
    var model = MyDAL.MyObjects.Where(x => x.Name == searchTerm); 
} 

no veo una diferencia de peso.

@La respuesta de Mark Seemann es igualmente inestable. Claro, puede cambiar toda su capa de datos en el medio de un proyecto, pero eso será un desastre complejo sin importar cuán abstraído se encuentre. El ejemplo que usa es cambiar de Linq2Sql al almacenamiento de tablas de Windows Azure. RDBMS a la tienda Key/Value? Y el punto de dolor es la implementación de su repositorio? Pasar de RDBMS a una tienda Key/Value va a ser una locura que va a ser horrible sin importar qué.

Mark también muestra el Dominio de diseño en su argumento. Es ese el tipo de sistema tu edificio. ¿Hay suficiente "Dominio" en lugar de escenarios CRUD puros que hacen que este enfoque sea valioso? Si no, ¿por qué molestarse?

El uso de LINQ y la interfaz IQueryable le proporciona menos dificultades para cambiar capas de datos de todos modos. Si su cambio entre ORM que admiten LINQ e IQueryableProvider (creo que ese es el nombre) que solo el código de abajo se preocupa por ese cambio. Sus controladores se mantendrían igual cambiando desde la mayoría de los ORM en el mercado ahora.