That is definitely not the case.
LINQ-to-Objects is a set of extension methods on IEnumerable<T>
that allow you to perform in-memory query operations on arbitrary sequences of objects. The methods accept simple delegates when necessary.
LINQ-to-Entities is a LINQ provider that has a set of extension methods on IQueryable<T>
. The methods build up an expression tree (which is why delegates are actually passed as Expression<>
s), and the provider will build up a SQL query based on its parsing of that expression tree.
As an example, consider the following queries:
var query1 = mydb.MyEntity.Select(x => x.SomeProp).Where(x => x == "Prop");
var query2 = mydb.MyEntity.Select(x => x.SomeProp).AsEnumerable().Where(x => x == "Prop");
The first query is will build up an expression tree consisting of a select and a where, with the two lambdas actually considered as LambdaExpression
s. The LINQ-to-Entities provider will translate that into SQL that both selects and filters.
The second query inserts an AsEnumerable()
, which will force the remainder of the query to use LINQ-to-Objects. In that case, the provider will generate SQL based on only the selection, return all those records from the database, and then the filtering will occur in-memory. Obviously, that's likely going to be much slower.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…