Проектирование системы значков, где можно запускать бизнес-логику? В коде или хранимых процедурах? или оба?

Ответ 1

Я бы рекомендовал разместить всю бизнес-логику в бизнес-слое. Я рекомендую это по нескольким причинам:

• Держите бизнес-логику в одном язык/место
• Масштабируемость - Вы можете разделить данные, реализовать различные механизмы кэширования и т.д.
• Отличие проблем - пусть ваша БД делает то, что она делает лучше всего... хранить данные, позволяя вашему языку программирования принимать решения по этим данным.

Ответ 2

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

Ответ 3

Лично я оставил бы базу данных для хранения/извлечения данных и имел логику в "бизнес-слое".

После успеха StackOverflow, я очень заинтересован в том, чтобы внедрить систему достижений для одного из моих сайтов, поэтому я сам подумал об этом.

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

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

Я предполагаю, что большая часть ответа на это будет зависеть от данных, на которых вы основываете награды на значке. Значки StackOverflow, по-видимому, основаны на данных (ответы, вопросы, голоса и т.д.) И событиях (изменения, повторная пометка и т.д.). Итак - алгоритм значка должен, вероятно, допрашивать какой-то журнал аудита или журнал действий.

Ответ 4

Итак - это классическая дискуссия SO и дебаты среди страстных программистов. Я задал аналогичный, но более общий вопрос об этом...

бизнес-логика в уровне базы данных

Чтобы ответить на первую часть, я нашел одно из лучших объяснений, которые я видел о бизнес-логике в базе данных кода и базы данных:

http://www.codeproject.com/KB/architecture/DudeWheresMyBusinessLogic.aspx

Далее объясняется, почему бизнес-логика намного лучше и масштабируемо. Я тоже нахожусь в этом вопросе... поэтому, чтобы ответить на ваш вопрос, я не буду вести бизнес-логику в БД или хранимых процедурах, поскольку основная причина среди многих других заключается в том, что SP не контролируются версией, а ее боль для контроля версий. Не говоря уже о том, что IDE для SP являются бесконечно более примитивными, чем IDE для кода. И sql/tsql, и подобные вещи не предназначены для сложной структуры кода, а для базового манипулирования данными и, как вы увидите в этой статье, для некоторой очень простой структуры кода, потому что ранее клиент-серверная архитектура была ограничена.

Некоторые исключения из этой страницы:

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

Не прошло много времени, чтобы понять, что пропускная способность сети может быть уменьшена и централизована логикой для уменьшения постоянных потребностей передислокации клиента путем перемещения большей части бизнес-логики из клиента. Поскольку было всего два уровня, единственным местом для перемещения бизнес-логики было сервер. Сервер в архитектуре был хорошо подходящим местом в клиентской серверной системе, но база данных как платформа была плохим выбором. Базы данных были разработаны для хранения и поиска, и их расширяемость была разработана для таких потребностей. Языки хранимых процедур базы данных были разработаны для базового преобразования данных в дополнение к тому, что не удалось сделать в SQL. Языки хранимых процедур были разработаны для выполнения очень быстро, а не для сложной бизнес-логики.

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

Бизнес-уровень должен содержать все бизнес-правила.

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

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

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

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

Однако иногда вам может пригодиться дублирование ОЧЕНЬ маленькой бизнес-логики для некоторого повышения производительности. Но, как вы видите в статье, бизнес-уровень в коде гораздо более масштабируемый, поэтому он может быть спорным.

Надеюсь, это полезная информация для вас, чтобы решить, что вам нужно...

Ответ 5

Я бы написал хранимую процедуру, так как вся необходимая информация находится в базе данных, поэтому это наиболее эффективное место для доступа к этим данным.

Типичное правило может быть реализовано с помощью одного оператора INSERT в следующих строках:

IF eligible for <new badge> THEN
    INSERT INTO user_badges
    SELECT <new_badge>
    WHERE NOT EXISTS (SELECT NULL FROM user_badges
                      WHERE badge = <new_badge>);
END IF;

(Я несколько упрощаю!)

Ответ 6

Я бы настоятельно рекомендовал оставить решения бизнес-логике, а не хранимым процедурам. Хранимые процедуры предназначены для обработки данных (т.е. Сбора данных, проверки конкретных состояний и условий, удаления, обновления, агрегирования и т.д.). Это не создание места для условной логики (принятия решений).

Что касается событий, данные стихов: все в системе достоинства (или, по крайней мере, может быть) основано на событиях.

данные (ответы, вопросы, голоса и т.д.) и события (изменения, повторная пометка, и др.)

... Все это события: ответы на вопрос, задание вопроса, голосование и т.д.

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

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

Метод VerifyCriteria будет хорошим примером возможного места для хранимой процедуры, особенно если вам нужна более высокая производительность. Это так же проверяет базу данных для конкретного состояния или состояния, так как это бизнес-логика. Некоторые значки могут потребовать некоторой обработки, которая сложна на языке базы данных (например, SQL), поэтому VerifyCriteria должен быть фактическим методом для объекта, который вызывает соответствующие хранимые процедуры и/или код. Это также помогает вашей логике бизнеса OO-friendly.

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

Ответ 7

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