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

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

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

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


sql-server vb.net data-access-layer business-logic-layer
person mick    schedule 24.01.2012    source источник
comment
Я всегда выполнял бы расчеты в базе данных, если ваш расчет должен был бы вернуть много данных на средний уровень, просто чтобы иметь, например. SUM рассчитано. Зачем отправлять все эти данные?? База данных хорошо оборудована для суммирования некоторых значений и отправки одного результата — намного эффективнее! Поэтому всякий раз, когда вам нужно сделать много, но мало вернуть, делайте это на сервере.   -  person marc_s    schedule 25.01.2012
comment
Я согласен с @marc_s SQL Server предназначен для быстрой и эффективной обработки данных.   -  person Mark Kram    schedule 25.01.2012

Ответы (3)


arrow_upward
6
arrow_downward

В принципе, я бы сделал в SQL Server все, что:

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

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

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

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

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

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

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

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

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

person marc_s    schedule 24.01.2012

arrow_upward
0
arrow_downward

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

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

person usr    schedule 24.01.2012
comment
Хранимые процедуры могут быть очень полезными, если они обрабатывают операции с базой данных и не скрывают бизнес-логику. Но для многих операций наличие хранимой процедуры может быть очень полезным. я бы не стал их банить глобально - person marc_s; 25.01.2012
comment
Спасибо, ребята, в основном, как только я собираю данные о том, какой курс был пройден, я отправляю отчет участнику для каждого штата, в котором они зарегистрированы, вместе со всеми их кредитами. Я считаю, что БД - правильное место для выполнения этих вычислений. Это был чистый парень vb.net/c#, который заставил меня задуматься, правильно ли я это делаю. Конечно, он утверждает, что все это должно быть сделано в BLL. Каждая ситуация отличается. - person mick; 25.01.2012
comment
Не применяйте строго передовые практики, такие как BLL и DAL, без здравого смысла. Имейте их в своем наборе инструментов и используйте, когда считаете нужным. - person usr; 25.01.2012

arrow_upward
0
arrow_downward

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

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

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

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

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

person Nat    schedule 24.01.2012