iqueryable

I've been learning about IQueryable and lazy loading/deferred execution of queries. Is it possible to expose this functionality over WCF? I'd like to expose a LINQ-to-SQL service that returns an IQueryable which I can then perform additional queries on at the client, and finally execute using a .ToList(). Is OData format applicable at all in this context? If possible, what is the term for this technique and what are some good tutorials I can follow? Thank you. You should check WCF Data Services which will allow you to define Linq query on the client. WCF Data Services are probably the only

I have to admit I have been carrying the "Repository should not return IQueryable" banner because it is harder to test. I have been influenced by the answers to other questions like this and this . This morning I've been reading ScuttGu's blog about ASP.NET vNext where he details Model Binding using a SelectMethod that seems to rely on IQueryable for paging and sorting. Do you think this will force us to reconsider the role IQueryable plays in repositories? DDD Repository should encapsulate data access technicalities: Definition: A Repository is a mechanism for encapsulating storage, retrieval

I want to create a DDD repository that returns IQueryable Entities that match the Linq to SQL underlying classes, minus any relations. I can easily return Entities minus the relations with a Linq select new {field, field, ... } projection. How do I code the Repository Entity class? How would I return an object from the repository having the repository class not the Linq to SQL class and still fill it with multiple entities from the Linq selection? How would I reference this returned class in my ViewModel? I am very new to this, thus the obvious mistakes. Am I missing the boat and should only

I am wondering what the difference between IQueryable, List, IEnumerator is and when I should use each one? For instance when using Linq to SQL I would do something like this: public List<User> GetUsers() { return db.User.where(/* some query here */).ToList(); } Now I am wondering if I should be using IQueryable instead. I am unsure of the advantages of using it over the list. Adam Robinson IQueryable<T> is intended to allow a query provider (for example, an ORM like LINQ to SQL or the Entity Framework) to use the expressions contained in a query to translate the request into another format.

I'm confused as to the difference. Being fairly new to .Net, I know I can query IEnumerables using the Linq extensions. So what is this IQueryable and how does it differ? See also What is the difference between IQueryable[T] and IEnumerable[T]? that overlaps with this question. Richard Szalay IEnumerable<T> represents a forward-only cursor of T . .NET 3.5 added extension methods that included the LINQ standard query operators like Where and First , with any operators that require predicates or anonymous functions taking Func<T> . IQueryable<T> implements the same LINQ standard query operators,

I have a repository class that wraps my LINQ to SQL Data Context. The repository class is a business line class that contains all the data tier logic (and caching and such). Here's my v1 of my repo interface. public interface ILocationRepository { IList<Location> FindAll(); IList<Location> FindForState(State state); IList<Location> FindForPostCode(string postCode); } But to handle paging for FindAll, I'm debating whether or not to expose IQueryable<ILocation> instead of IList to simplify the interface for circumstances such as paging. What are the pros and cons to exposing IQueryable from the