Метод DataContext.GetTable () вернет объект типа:
System.Data.Linq.Table
Делая это, я предполагаю, что я не отправил вызов в базу данных, чтобы получить всю таблицу. В противном случае LINQ будет несколько неэффективным.
Поэтому все, что я сделал, это углубился в мой строго типизированный класс Datacontext (например, dbDataContext), чтобы получить дескриптор, например, его свойства «Customers», которое представляет таблицу Customers в SQL Server.
Затем я могу получить IQueryable от объекта, возвращаемого GetTable (), и все еще не попал в базу данных. То есть, мой код 'Service Layer' будет LINQ to Objects, а не Linq to Sql.
Сделав все это, я уменьшу количество нужных мне репозиториев.
Вопрос:
Верны ли вышеизложенные предположения?
Примечание:
Я пытаюсь найти способ построить мои Запросы с использованием интерфейсов и обобщений, чтобы сделать его тестируемым и все такое ...
Итак, размышляя в духе ответа @ zowen:
Шаблон репозитория: один класс репозитория для каждой сущности?
Я пытаюсь реализовать
public interface IQueryProvider<T>
{
TResult Query<TResult>(Func<IQueryable<T>, TResult> query);
}
Я знаю, что в этом нет особой необходимости, но я прохожу курс обучения и рассматриваю архитектурные варианты, которые мне подходят, и то, как я думаю.
Что я пытаюсь сделать:
Я пытаюсь реализовать следующее для SQL Server вместо 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());
}
}
Я хочу получить дескриптор GetTable (), а затем написать мой код Service Layer Linq для этого.
Я подозреваю, что мне придется написать интерфейс-обертку, чтобы получить эквивалент переменной базы данных IMongoDatabase.
Однако вопрос в том, что выше, а не в другом. Как я уже сказал, я только учусь здесь. В этом фильме не будет никакого производственного кода.