Бизнес уровень против SQL Server

Question

У меня есть приложение, которое выполняет сложные расчеты для членов.Каждый участник может иметь несколько штатов США, связанных с их профилем.Каждое государство имеет различные расчеты для каждого курса, который завершает участник.

На данный момент я выполняю вычисления в БД (SQL Server 2008), а затем отправляю данные обратно на уровень приложения, где они могут видеть свою историю, а затем загружает сертификат для каждого курса.

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

Answer 1

Я бы в основном делал в SQL Server все, что:

• выполняет много суммирования, подсчета, усреднения и т. Д. Данных и возвращает только одно значение.На самом деле нет смысла переносить большие объемы данных на средний уровень, просто для суммирования столбца

• выполняется много манипуляций на основе строк / наборов;если вам нужно скопировать, вставить, обновить много данных, опять же, нет смысла перетаскивать все эти данные на средний уровень, а затем отправлять их обратно на сервер - делайте это на сервере с самого начала.Кроме того: T-SQL значительно быстрее справляется с операциями на основе множеств (например, перетасовывает данные), чем что-либо на вашем среднем уровне:

Вкратце: старайтесь избегать отправки больших объемовданных на клиентский / средний уровень / бизнес-уровень, если только вам это не нужно (например, потому что вы хотите загрузить файл, хранящийся в базе данных, или если вам действительно нужно , чтобы эти 200 строк материализовались в объектыв вашем приложении, где-то отображаться или работать)

Одна из часто упускаемых функций - вычисляемые столбцы прямо в таблице базы данных - они действительно хороши при суммировании, например, суммы вашего заказа плюс налоги отправка в общий итог, или они здорово объединить ваше имя и фамилию в отображаемое имя.Такие вещи действительно не должны обрабатываться только на уровне бизнес-логики - если вы выполняете их непосредственно в базе данных, эти «вычисленные» значения также доступны вам, когда вы просматриваете таблицы базы данных и просматриваете данные в SQL Server.Mgmt Studio ...

---

Я бы поместил его на уровень среднего уровня / бизнес-логики

• , если бы требовалась обширная логическая проверка, разбор строк, сопоставление с образцоми так далее;T-SQL отстой в этих вещах

• , если требуются такие вещи, как вызов веб-службы для получения каких-либо данных для проверки ваших данных или что-то подобное

• , если требуется больше операций бизнес-логики (вместо строгих «атомарных» операций с базой данных)

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

Answer 2

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

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

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

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

Таким образом, вполне допустимо рассчитывать данные наиболее эффективным способом (например, sql), если эти вычисления имеют соответствующее представление в бизнес-логикеслой.

Answer 3

Это помогает не иметь код бизнес-логики внутри базы данных (хранимые процедуры). Гораздо лучше иметь его непосредственно в приложении, чтобы оно соответствовало архитектуре. Этот код SQL содержит вашу бизнес-логику, и в этом нет ничего плохого. (Нет ничего плохого в том, что в sprocs есть код данных или обслуживания).

Если уровень вашей бизнес-логики мало что делает, а просто передает данные из SQL Server вызывающей стороне, возможно, вам это вообще не нужно.