Так було

Протягом багатьох років я організовував свої програмні рішення як такі:

• Шар доступу до даних (DAL) для абстрагування доступу до даних
• Бізнес-логічний шар (BLL) застосовує бізнес-правила до наборів даних, обробляє автентифікацію тощо.
• Утиліти (Util) - це лише бібліотека поширених утилітних методів, які я створив з часом.
• Презентаційний шар, який, звичайно, може бути веб, настільний, мобільний, будь-який інший.

Так, як зараз

Останні чотири роки або близько того я використовую Entity Framework Microsoft (я переважно є NET-розробником), і я виявляю, що наявність DAL стає більш громіздкою, ніж чистою через те, що Entity Framework вже зробив робота, яку раніше виконував мій DAL: вона абстрагує роботу із запуском CRUD-файлів щодо бази даних.

Отже, я зазвичай закінчую DAL, який має набір таких методів:

public static IQueryable<SomeObject> GetObjects(){
    var db = new myDatabaseContext();
    return db.SomeObjectTable;
}

Потім у BLL цей метод використовується як такий:

public static List<SomeObject> GetMyObjects(int myId){
    return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}

Це простий приклад, звичайно, оскільки BLL, як правило, застосовує ще кілька ліній логіки, але це просто здається трохи надмірним для підтримки DAL для такої обмеженої області.

Не було б краще просто відмовитися від DAL і просто написати свої методи BLL як такі:

public static List<SomeObject> GetMyObjects(int myId){
    var db = new myDatabaseContext();
    return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}

Я розглядаю можливість відкинути DAL з майбутніх проектів з причин, зазначених вище, але, перш ніж це зробити, я хотів опитати тут спільноту щодо вашої оглядовості / передбачення / думки, перш ніж спуститися на проект і виявити проблему, яку я не зробив '. t передчувати.

Будь-які думки цінуються.

Оновлення

Здається, що думка полягає в тому, що окремий DAL не потрібен, але (роблячи тут власний висновок) - це гарна ідея, щоб уникнути блокування постачальника. Наприклад, якщо у мене є DAL, який дозволяє абстрагувати виклики EF, як показано вище, якщо я коли-небудь перейти на якогось іншого постачальника, мені не потрібно переписувати свій BLL. Необхідно буде переписати лише ті основні запити в DAL. Сказавши це, мені складно передбачити сценарій, в якому це відбудеться. Я вже можу зробити модель EF для Oracle db, MSSQL - це дані, я майже впевнений, що MySql також можливий (??), тому я не впевнений, чи зможе додатковий код коли-небудь дати гідну рентабельність інвестицій.

Не впевнений, чи це відповідь, яку ви шукаєте .. але ось що.

Ми робимо це, щоб все було розділеним / організованим. Так, EF / NHibernate - це доступ до даних .. але ми обмежуємо його використання власною збіркою із загальною установкою сховища. Ця збірка також містить всі наші відображення NHibernate, фабрику сесій, код для обробки декількох баз даних тощо.

Ми все ще називаємо це "шаром доступу до даних", оскільки вся збірка існує для підтримки нашого ORM.

Я, мабуть, зауважу, що наш основний додаток посилається на 5 баз даних, має приблизно 4-500 доменних об'єктів / відображень та різні схеми. Отже, ця установка має для нас сенс. Можливо, для меншого додатка ви пропустили б цю збірку, але .. Я є присоскою для організованого коду і, мабуть, зробив би це все одно :)

Я розглядаю EF та DAL як окремі компоненти в системі Enterprise. Шар доступу до даних - це абстракція, яку використовують інші служби для збереження даних та управління ними. Зазвичай Entity Frameworks будує приємний API навколо запитів, оновлення, видалення та вставки, однак в основі вони все ще потребують прямого підключення до резервного джерела даних. Таким чином, будь-який тип маршрутизації або брандмауери зупинить роботу EF, тим самим вимагаючи створити компонент посередництва EF.

Ось приклад високого рівня, який показує, куди вписуються DAL та EF:

-------------    -------                                    ----------------    ------
| Service A | -> | DAL | -> { LOCAL / LAN / WAN ACCESS } -> | DAL BACK-END | -> | EF |
-------------    -------                                    ----------------    ------

Мій досвід був кращим дизайном - ніколи не дозволяти бізнес-логіці чи впровадженню послуг прямого доступу до рівня EF. Натомість, щоб отримати абстракцію для роботи з усіма стійкими даними, що дозволяє надсилати запити по дроті або виконувати їх на локальному рівні.

Цей дизайн вводить деякі протікаючі абстракції. Тож це слід розглядати у кожному конкретному випадку.

Деякі запитання:

• Чи зможуть усі компоненти, що отримують доступ до ваших даних, отримати з'єднання із резервним сховищем даних?
• Чи дозволяє ваш EF дозволяти агрегувати набори даних у різних типах сховищ даних? Наприклад, використання бази даних SQL з MongoDB для документів.

Сьогодні питання про те, чи збираєтесь ви змінювати сховище даних, цікавіше, ніж раніше, оскільки питання може бути не лише в тому, чи будете ви обмінюватися між MS SQL чи Oracle SQL, але більш важливим питанням є ви може використовуватись із різних пропозицій зберігання даних NoSQL в якості сховища даних.

Якщо існує серйозна можливість подібного роду змін, можливо, буде важливо тримати ваш код EF ізольованим у вашому DAL, щоб у майбутньому ви могли запровадити новий DAL, який відображав запити вашого сховища до бази даних NoSQL. Можливо, така зміна все-таки закінчиться оптовим переписуванням вашого BLL через припущення, пов'язані з db, які, звичайно, повзуть.

Аналогічно, EF у домені DAL, ймовірно, зробить глузування доступу до даних для ваших тестів блоку коду BLL більш простим.

Отже, я вважаю, що EF (або інші ORMS) не обов'язково анулюють потребу в рівні доступу до даних.