Рекомендуется гибрид 2-х и 3-х уровневой архитектуры

Question

Я создаю веб-приложение, которое принимает различные бизнес-правила в качестве входных данных и сохраняет их в базе данных.Это делается с помощью 3-уровневой архитектуры.

После этого я должен использовать ВСЕ эти бизнес-правила в одной операции, поэтому я пишу бизнес-логику для этой части в хранимой процедуре и вызываю ее из пользовательского интерфейса, делая ее двухуровневой.

Поскольку это редкая ситуация, когда все данные (а это значительный объем - сам SP занимает около 6 минут на обработку) необходимы для одной операции, и для меня не имеет смысла извлекать все данныекак объекты в BLL только ради сохранения архитектурной целостности.Кроме того, логика в SP является итеративной, и поэтому все данные должны храниться в BLL и не могут быть получены условно.

Пожалуйста, предложите мне, если у меня правильный подход или нет.

Answer 1

@ APC верен, логика должна жить там, где это наиболее уместно - и:

• Пользовательский интерфейс должен все еще проходить через уровень BL для доступа к данным, чтобы ваше приложение было последовательно структурировано.
• Если вы собираетесь использовать логику в разных местах приложения (для удовлетворения определенных требований, например, производительности), вы должны четко задокументировать, каковы эти определяющие факторы, и разработчикам, которые следуют за ними, должно быть легкоиз.

На ум приходят два варианта (относительно структуры):

• Один из способов убедиться, что приложение правильно структурировано и понятно, состоит в том, чтобы изолировать конкретные «тяжелые» задачи по интерфейсу.,В идеале весь ваш доступ к данным должен быть в любом случае уже абстрагирован интерфейсами, и они должны быть разбиты на логические области (см. Принцип разделения интерфейсов - ISP).Таким образом, у вас может быть выделенный интерфейс для конкретных нужд доступа к данным: [BL] -> [IDataAccess] -> [Доступ к конкретным данным]
• Другой подход (но в том же духе): вместо доступа к BLэти специальные вызовы данных, такие как обычный доступ к данным, включают или вводят его как BL.

Как использовать второй подход: Определите интерфейс (на уровне BL), который будет использоваться другими бизнес-объектами: [BL Object] -> [ISpecialBusinessLogic] -> [Конкретная реализация].Конкретная бизнес-логика может быть чем угодно, но в вашем случае это будет вызов специального метода / компонента доступа к данным, где вы выполняете «тяжелую работу».

Когда вы реализуете свой доступ к данным, выесть возможность делать все это в одном классе / компоненте (который реализует несколько интерфейсов) или в отдельных классах / компонентах, каждый из которых реализует один интерфейс.

Answer 2

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

Кроме того, в будущем, если вам потребуется применить некоторую бизнес-логику к данным, возвращаемым вашим SP, то вы будете делать это в своем BL.

Answer 3

Бизнес логика принадлежит там, где она наиболее уместна. Если у вас есть логика, которая связана с данными и которая когда-либо выполняется только хранимой процедурой, то база данных является подходящим местом для ее хранения.