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


Answers

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

Question

Если бы вы создали систему значков, аналогичную тому, как это делается SO, вы бы поместили логический / бизнес-уровень в базу данных напрямую (через хранимую процедуру, запланированные SQL-задания) или поместили ее на сервер?

Из того, что я могу придумать, вы должны:

  1. список значков, которые относятся к текущему действию пользователя
  2. проверьте, есть ли у пользователя значок уже или нет
  3. вставить значок для пользователя

Возможные варианты

  1. бизнес-логику в веб-приложении, которая вызывает хранимые процедуры и т. д.
  2. ТОЛЬКО хранимые процедуры
  3. Работа сервера sql, выполняемая каждые x минут
  4. служба Windows, которая запускается каждые x минут

Будет ли их комбинация обязательной? Я думаю, что с тех пор, как некоторые значки основаны на вехах для заданного вопроса, может быть, пакетная работа лучше?

Обновить

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

интересная проблема решить !!




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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




Links