Work with DataContext.GetTable <T> () to get "QueryProvider"
The DataContext.GetTable () method returns an object of type:
System.Data.Linq.Table
Having done this, I believe that I did not issue a call to the database to retrieve the entire table. Otherwise, LINQ will be somewhat inefficient.
So all I did was drill into my highly typed Datacontext class (like dbDataContext) to grab a handle, like its “Customers” property, which represents the Customers table in SQL Server.
Then I can get IQueryable from the object returned by GetTable () and still not hit the database. Those. my "Service Layer" code will be LINQ for objects, not Linq to Sql.
By doing all this, I will reduce the number of repositories I need.
Question:
Are these assumptions correct?
Note:
I am trying to figure out a way to create my queries using interfaces and generics to make it verifiable and all that doo dah.
So, reflecting on the lines of @zowen's answer to:
Sample repository: one repository class for each object?
I'm trying to implement
public interface IQueryProvider<T>
{
TResult Query<TResult>(Func<IQueryable<T>, TResult> query);
}
I know that this is not necessary, but I look at the learning curve and look at the architectural options that suit me and what I think.
What am I trying to do:
I am trying to implement the following for SQL Server instead of MongoDb:
public class MongoQueryProvider<T> : IQueryProvider<T>
{
private readonly IMongoCollection<T> collection;
public MongoQueryProvider(IMongoDatabase database)
{
this.collection = database.GetCollection<T>();
}
public TResult Query<TResult>(Func<IQueryable<T>, TResult> query)
{
return query(this.collection.Linq());
}
}
I want to get the GetTable () handle and then write my Linq Layer Layer code.
I suspect that I will have to write a shell interface to get the equivalent of the IMongoDatabase database variable.
, , . , . .