ASP MVC: Should services return IQueryable's?

What do you think? should your DAO return an IQueryable to 开发者_StackOverflowuse it in your controllers?

---

No. Your controllers shouldn't be handling any complex logic at all. Keep them slim; the Model (not DAO) should hand the Controller back everything it needs to pass onto the View.

Seeing queries (or even queryables) in a Controller class is something I would consider to be a code smell.

---

At the moment, it sounds attractive, but really isn't.

---

I love passing IQueryable into my controllers because I don't have to create lame paging and sorting methods in every single DAO method and interface throughout the lifetime of my apps development.

GetCustomersByLastname( string lastname )

Quickly Becomes

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

Again and again and again and again. Bleck!

With IQueryable you can take implement paging and sorting in orthogonal ways such as taking advantage of the IPagedList project. Returning IQueryable also give you easy access to total object .Count() without more perversion of your data layer.

@Robert s argument of IQueryable equals fat controllers is very shaky. A Fat controller would be similar to the bloated .aspx.cs pages of yore. If all your doing is connecting to your DAL and then shipping the results off your don't gain "fatness" from your query technique, you gain it from shoving lots of logic inside inside a single class. You do not get a Fat Controller because of your data access methods unless you start rolling logging, notifications, and other orthogonal concerns inside.

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 );
}

I don't see a compelling difference.

@Mark Seemann 's answer is equally shaky. Sure, you may change your entire data layer in the middle of a project but that is going to be a complex disaster no matter how abstracted you are. The example he uses is switching from Linq2Sql to Windows Azure's table storage. RDBMS to Key/Value store? And the pain point is your Repository implementation? Going from RDBMS to a Key/Value store is going to be some craziness thats going to be horrible no matter what.

Mark also brings up Domain Driven Design in his argument. Is that the type of system your building. Is there enough "Domain" rather than pure CRUD scenarios that make this approach valuable? If not then why bother?

Using and LINQ and the IQueryable interface gives you less of the pain of switching data layers anyway. If your switching between ORMs that support LINQ and IQueryableProvider ( I think thats the name ) than only the downstream code cares about that change. Your controllers would stay the same switching between from most ORMs on the market now.

---

If you follow the "fat models, skinny controllers" paradigm then no.

See this post on the Fat Controller anti-pattern.