Методы запросов LINQ на уровне доступа к данным (DAL) - PullRequest
Новая
       23

Методы запросов LINQ на уровне доступа к данным (DAL)

2 голосов
/ 03 ноября 2010

Проект базируется на классических 3 слоях: пользовательский интерфейс (не важно в этом вопросе), уровень бизнес-логики и уровень доступа к данным.У меня есть несколько таблиц: Customers Products Orders Users.Предполагается, что дизайн: 

//DAL methods
public IEnumerable<Customer> GetAllCustomers()
public IEnumerable<Product> GetAllProducts()
public IEnumerable<Order> GetAllOrders()
public IEnumerable<User> GetAllUsers()
//BLL methods
public IEnumerable<Order> GetOrders(long CustomerID)
public IEnumerable<Product> GetProducts(long CustomerID)
public IEnumerable<Product> GetProducts(long OrderID)

Что меня смущает, так это то, что я обнаружил, что все методы в DAL - это GetAllXXXX.И я должен признать, что этот дизайн работает нормально.В DAL нет ничего, кроме методов GetAll.В BLL нет ничего, кроме комбинированных операций (filter / join / select) для методов GetAll.Это странно?Какой правильный путь?

Ответы [ 3 ]

2 голосов
/ 03 ноября 2010

Нет, это не странно, и на самом деле это очень похоже на то, как я это делаю.

Только различия для меня:

  • Я использую IQueryable<T> вместо IEnumerable<T> (для получения отсроченного исполнения)
  • У меня есть общий репозиторий (Repository<T>):
    • IQueryable<T> Find()
    • void Add(T)
    • и т. Д.

Таким образом, мои хранилища остаются чистыми / простыми.

Таким образом, ваш BLL может быть реализован так: 

public IEnumerable<Order> GetOrders(long CustomerID)
{
   Repository<Order> orderRepository = new Repository<Order>(); // should use DI here, but i digress
   return orderRepository
             .Find() // no query executed...
             .Where(o => o.CustomerID == CustomerID) // still nothing...
             .ToList(); // query executed, with BL applied! cool!
}

Заставляет BLL выполнять проекцию / работу / логику. Хранилища просто обрабатывают постоянство T, не заботятся о реальном типе или какой-либо бизнес-логике.

Вот так все и делаю.

1 голос
/ 03 ноября 2010

Учтите, что ваш уровень доступа к данным может предоставлять такие услуги, как:

  • Создать
  • Обновить
  • Удалить
  • GetSingleCustomer()
  • CalculateUpperManagementTuesdayReport()

Я бы не сказал, что это ужасно странно, но, возможно, вашему DAL не нужно предоставлять эти услуги, поскольку ваше приложение этого не делает.потребовать их.

Имея ваш фильтр / соединение / выбор в BL, я бы предпочел IQueryable<t> вместо IEnumerable<T>.Это означает, что выполнение данного оператора в коде BL не произойдет, пока вы не вызовете Single(), First(), ToList(), Count() и т. Д. И т. Д. В коде BL.

0 голосов
/ 03 ноября 2010

Мой вопрос: что вы потеряете, если объедините текущий BLL и DAL? - кажется, что они оба имеют дело с преодолением разрыва от постоянных данных (БД) до объектов. Другой способ взглянуть на это - это локализованные изменения? например если в слое DAL произойдет изменение, будет ли он изолирован или будет распространяться на верхние слои (что нежелательно).

В идеале BLL должен инкапсулировать правила / рабочие процессы вашего домена, иначе говоря, о знании домена. например если к определенным клиентам относятся по-разному. DAL существует для преобразования ваших данных из постоянного состояния в объекты (или структуры данных, которые будут использоваться верхними уровнями) и наоборот. Это мое понимание на сегодня ...

...