Где разместить бизнес-логику при использовании Entity Framework и ASP.NET

Question

Обычно я начинал новые проекты с решения, содержащего:

• Веб-проект : содержит контроллеры ASP.NET MVC или Web API, код Javascript и т. Д.Делает вызовы в библиотеку классов

• Библиотека классов 1 : содержит DbContext, модель данных EF, класс с методами CRUD для взаимодействия с Db через DbContext иразличные «служебные» методы

• Библиотека классов2 : содержит только классы POCO.На эту библиотеку ссылаются как веб-проект, так и библиотека1

Хорошо, это работает хорошо, но когда количество «бизнес-логики» начинает увеличиваться, это становится немного грязно, так как я начинаювставляя больше правил, которые дает вам бизнес.Заставляет меня думать, что нужен еще один «слой» или библиотека, куда мы помещаем «бизнес-логику», которая на самом деле выше / выше простого получения данных, возвращаемых в виде отфильтрованного списка объектов POCO.Такие вещи, как проверка атрибутов заказов, основанные на некоторых правилах, определенных какой-либо группой в рамках бизнеса.

Мой вопрос: вы бы заставляли каждый вызов на уровне клиента проходить через бизнес-библиотеку (см. Рисунок ниже# 2), даже для простых случаев, когда вам просто нужен какой-то простой список значений поиска?

Answer 1

Этот вопрос, вероятно, привлечет взвешенные ответы.Мое предположение - да, я бы заставил все пройти через бизнес-библиотеку.

Чтобы иметь согласованность больше, чем что-либо на самом деле, таким образом вы можете быть уверены:

• Новыйчлен вашей команды не пытается понять, почему некоторые операции с БД происходят через другой уровень по сравнению с другими.
• Когда вы (или какой-либо другой разработчик) добавляете / удаляете функции, относящиеся к взаимодействию сБД, ее местонахождение хорошо известно.
• Когда есть проблема, касающаяся уровня / доступа / запросов БД - проще найти проблему.
• Если вы тестируете этот слой / методы -мы считаем, что удобнее иметь все в одном месте.(Тестируемость определенно возрастает.) Мы все еще разделяем вещи по файлам.
• Мы используем Dependency Injection - поэтому, если вам нужен доступ к БД, вы просто внедряете интерфейс, который устанавливает соединение для вас, и все готово.
• В зависимости от того, как настроена ваша система, если вы регистрируете вещи, связанные с БД, отдельно (например, отслеживая QoS запросов отдельно), это также гарантирует, что вы не добавите эту пользовательскую регистрацию по всему кодудля этих простых поисков.
• Делает цепочку зависимостей более управляемой.

Теперь - это не значит, что это не сложно, это делает,Однако есть и другие способы разделения вещей: вам необязательно иметь гигантский класс DBContext, который обрабатывает N различных запросов, в зависимости от нашего дизайна, в итоге мы могли бы разделить его на такие разные частичные классы.функциональные возможности оказываются в разных файлах, их тесты также отображаются в разные файлы;мы считаем, что это улучшает общую ремонтопригодность.