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
LambdaExpressions. 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.