Your posting appears to confuse a number of different terms, but I think I can tell you what you want to know.
When you write a LINQ query on Container.Instances<T>() (whether directly in your code, or via one of the helper methods in AbstractFactoryAndRepository) then Naked Objects simply passes this query on to Entity Framework (i.e. as 'LINQ to Entities'),
which compiles the query tree in an efficient manner and executes it as sql instructions to the database. This is the correct way to do querying, for a high performance enterprise systems. Naked Objects does not touch the query. The query executes just as
efficiently as if you had written a native .NET application that invoked the query on the appropriate DbSet.
'LINQ to SQL' ia a different technology, which was developed by an independent group at Microsoft (apparently the two groups didn't know about each other - an interesting story!) It is pretty clear that Microsoft sees LINQ to Entities as the strategic option.
We have no plans to build a LINQ to SQL implementation, for that reason. If your concern is about the relative efficiency of LINQ to Entities and LINQ to SQL, that question is best directed to the Microsoft forums. I recommend, though, that you read Julie
Lerman's book on EF, if you haven't already.
'Dynamic LINQ' is something altogether different - see
. It is a library to allow you to build LINQ queries dynamically, at run-time, using strings. It is nothing to do with how/where the query is executed. Naked Objects uses Dynamic LINQ
for the methods DynamicQuery and DynamicQueryWithType on AbstractFactoryAndRepository - which are intended to allow a power-user to enter a custom query definition as a string via the UI, and execute it. Dynamic LINQ seems to be a bit of a dead
project though - it has not been maintained much by Microsoft. It makes for a nice demo, but I can't say I've ever used it for real on an enterprise system. Ordinary LINQ to Entities queries, written on Container.Intances<T>() do not use Dynamic LINQ.
I recommend against accessing the context directly (e.g. via (ObjectQuery)Container.Instances<type>()).Context. ) unless you absolutely need to - e.g. to invoke a stored proc. It is no more efficient for ordinary queries.
The only overhead added by going through Container.Instances() is if you are working with multiple DbContexts, in which case NO has to figure out which DbContext to forward the query on to. For people who do a lot of this, we recently introduced the AssociateTypes
method, to make that look-up more efficient - but this is of no relevance if you have a single DbContext. Also, that was only ever an overhead
the query was executed: there was no impact on the efficiency of query execution.
Hope that helps.