You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Entity Framework should support constructing IQueryable instances outside the DbContext and attaching for execution. Conceptually this is similar to NHibernate's DetachedCritera class. An api might look something like:
var q = DetachedQuery.Of<Student>().Where(s=>s.GPA > 3.0 && s.LastName.StartsWith("Q"));
...
var qStudentsWithGoodGrades = schoolDb.Search(q);
Why: This makes it easier to encapsulate and unit test potentially complicated query construction logic such as search forms. The relevant fields can be wrapped up into a class with a method or methods that construct the relevant detached query. Unit tests can then construct the class and inspect the result of the query construction. This is particularly useful in a WebApi scenario where the model class in the GET method can fully encapsulate the querying logic.
The implementation is fairly trivial. DetachedQuery.Of<TEntity>() returns an IQueryable with a dummy root ConstantExpression. Before execution schoolDb.Search<TEntity>() rewrites the expression tree replacing the dummy constants with EntityFramework DbSets or any other source of IQueryable instances.
Questions:
Is this something anyone would even want?
Is this something more appropriate for a different layer of the framework? Should the API for creating and rewriting DetatchedQueryables be defined elsewhere so that other projects can use this without depending on EntityFramework?
Is this better off as one or more separate nuget packages entirely? Technically this depends on only public API calls.
The text was updated successfully, but these errors were encountered:
@jeffreyabecker This does sound to me like something that could be built to work independently of EF.
On the other hand as @anpete suggested earlier today it should be easy in C# to create a method (or lambda) that takes the IQueryable<T> root as an argument and then applies all the query operators to it. Once you have this you can choose to apply it to a dummy root (if the goal is just to inspect the tree) to an in-memory (i.e. LINQ to Objects) IQuerable<T> or to an EF DbSet<T>, e.g.:
Given how easy this is with LINQ (Hibernate/NHibernate probably had to come up with its own mechanism) I am not sure there is much value in the feature.
@divega There is actually a pretty similar type of implementation that is part of an Unit of Work and Repository Framework that is on CodePlex ( https://genericunitofworkandrepositories.codeplex.com ).
They can find examples under the samples code area that shows how it is implemented with some custom queries for the Northwind database.
It's basically the same type of process that you talk about above.
This is a feature request
Entity Framework should support constructing IQueryable instances outside the DbContext and attaching for execution. Conceptually this is similar to NHibernate's DetachedCritera class. An api might look something like:
Why: This makes it easier to encapsulate and unit test potentially complicated query construction logic such as search forms. The relevant fields can be wrapped up into a class with a method or methods that construct the relevant detached query. Unit tests can then construct the class and inspect the result of the query construction. This is particularly useful in a WebApi scenario where the model class in the GET method can fully encapsulate the querying logic.
The implementation is fairly trivial.
DetachedQuery.Of<TEntity>()
returns an IQueryable with a dummy root ConstantExpression. Before executionschoolDb.Search<TEntity>()
rewrites the expression tree replacing the dummy constants with EntityFramework DbSets or any other source of IQueryable instances.Questions:
The text was updated successfully, but these errors were encountered: