I am copying (and slightly modifying so that it is not out of context) a forum post that I wrote to put here in my blog. Here's the original thread if you are interested.
When working with object services, you can query data using LINQ to Entities or ObjectQueries with Entity SQL.
Unless you specifically use LINQ syntax in your EF query, it will be an ObjectQuery.
An example.
context.Customers is an ObjectQuery. The same as context.CreateQuery<Customer>("SELECT c FROM myentitycontainer.Customers as c") or even context.CreateQuery<TEntity>(entitySetNameString) if you want to do this generically as Graham Hay shows earlier in this thread.
from cust in context.Customers blah blah is a LINQ to Entities query.
The first example (return context.Customers) however takes advantage of EF's query builder methods which will literally construct a nice ESQL query and create an objectQuery for you. There are not a lot of ESQL Query Builder methods but some of them overlap with LINQ methods.
Check out the difference here:
var q1=context.Customers.Where("it.FirstName='Julie'")
var q2=context.Customers.Where(c=>c.FirstName=="Julie")
The first uses a query builder method and ESQL syntax in the where parameter, therefore EF will know that you are using the Where Query Builder method, not the LINQ to Entities one. But the second uses a lambda so EF knows that's LINQ.
At run time, after the first line of code has been executed (not the executing the query, just the creating q1), you can debug q1 and see that it is an ObjectQuery<Customer> and that it has a command text value that is an ESQL Query
"SELECT VALUE it\r\nFROM (\r\n[Customer]\r\n) AS it\r\nWHERE\r\nit.FirstName='Julie'"
Because the second query has some very specific LINQ to Entities syntax in it, EF determines that this is a LINQ to Entities query. When debugging Q2, the value of q2 will be an objectQuery<Customer> but the TYPE of Q2 will be a System.LINQ.IQueryable. The CommandText property is empty.
LINQ to Entities and ObjectQuery queries are processed differently as well. The first few steps for each are unique to the query method, then at some point in the query pipeline, they meet on a common path.
Don't discount ObjectQuery as a query option because it is that class that allows you to more readily use generics and build dynamic queries.
To use generics in a real LINQ to entities query, you would probably have to do functional programming.
This is why ObjectQueries are so powerful. You can use generics with them. You can build queries dynamically.
But don't expect to do it using the strongly typed classes. Use CreateQuery or new ObjectQuery and then pass in the generic type (e.g. TEntity) and the Entity SQL string.