Как это было

В течение многих лет я организовывал свои программные решения как таковые:

• Уровень доступа к данным (DAL) для отвлечения бизнеса от доступа к данным
• Уровень бизнес-логики (BLL) для применения бизнес-правил к наборам данных, обработки аутентификации и т. Д.
• Утилиты (Util) - это просто библиотека общих утилитных методов, которые я создал со временем.
• Уровень представления, который, конечно, может быть веб, настольным, мобильным и прочим.

Так оно и есть сейчас

В течение последних четырех лет я использовал Microsoft Entity Framework (я в основном являюсь разработчиком .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 из будущих проектов по причинам, указанным выше, но прежде чем сделать это, я хотел бы опросить сообщество здесь, чтобы узнать о ваших взглядах / предвидениях / мнениях, прежде чем приступить к реализации проекта и обнаружить проблему, которую я не обнаружил. не ожидаю.

Любые мысли приветствуются.

Обновить

Похоже, что консенсус заключается в том, что отдельный DAL не нужен, но (делая мой собственный вывод здесь) хорошая идея, чтобы избежать блокировки поставщика. Например, если у меня есть DAL, который абстрагирует вызовы EF, как показано выше, если я когда я переключаюсь на другого поставщика, мне не нужно переписывать свой BLL. Только те базовые запросы в DAL должны быть переписаны. Сказав это, мне трудно представить сценарий, в котором это произойдет. Я уже могу сделать EF-модель базы данных Oracle, 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 из-за допущений, связанных с БД, которые, конечно, закрадываются.

Точно так же EF в DAL, вероятно, сделает более простым моделирование доступа к данным для ваших модульных тестов кода BLL.

Поэтому я считаю, что EF (или другие ORMS) не обязательно отменяют необходимость в уровне доступа к данным.