Question

When using Linq2Nibernate is better to make you Repository return a IQueryable?

My understanding is that if you use Linq to Nibernate the the query will not ‘fire’ until you call .First() or Single() ect ect. So would it not be best to return IQueryable from all you Interfaces so you can build up\manipulate the expression tree before it fires?

My Repositories are called by a services and inherits from IServicie.

EDIT:

First I really appreciate all the answers. But I wan to add a little to the question. I am for this design. I don’t fully understand the reservations around testing. As long as the process is tested at every point IE every filter point then I don’t really see much of a difference.

addition:

Is there any point to Using Linq2Nibernate if your repository doesn’t return IQuerrable?

Answer 1

Personally, I think not. The problem with exposing composable queries from your repository is that you can no longer fully unit test them – their behaviour (and success) is now at the mercy of the caller. For example, they might do .Where(x=>SomeUnmappedMethod(x)) (with no translation). I added more on this here.

If you have fixed methods that return (for example) IList<T> or T[], then you can be sure that if it works in the unit test, it should work for real (barring any configuration errors). It also means that you can profile the DAL in isolation and have reasonable confidence what SQL (etc) is going to be executed. You can’t profile/optimise a DAL that changes based on the caller.

(based on my LINQ-to-SQL usage; not LINQ-to-NHibernate specifically)