Плюсы и минусы в том, где разместить бизнес-логику: уровень приложения или БД

Question

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

Кстати, мы находимся в контексте веб-приложений (имеющих базу данных Oracle), и наш текущий подход заключается в том, чтобы

• Уровень пользовательского интерфейса, который принимает входные данные пользовательского интерфейса и выполняет первую проверку на стороне клиента
• Бизнес-уровень с несколькими классами обслуживания, который содержит бизнес-логику, включая проверку ввода данных пользователем (на стороне сервера)
• Уровень доступа к данным, который вызывает хранимые процедуры из БД для выполнения операций сохранения / чтения

Однако многие люди склонны переносить вещи бизнес-уровня (особенно в отношении проверки) в БД с точки зрения хранимых процедур.

Что вы думаете об этом? Я хотел бы обсудить.

Answer 1

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

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

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

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

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

Answer 2

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

Итак, предположим - это может быть проект 1 на 50+ сенарио?

Вы определяете факторы, которые будут:

• Право собственности: кому (какой системе / компоненту) принадлежат данные, а кому - правила / логика, которые к ним относятся? Если база данных «принадлежит» определенному компоненту, то он должен содержать бизнес-логику, поскольку база данных является просто ее хранилищем; если база данных является сущностью сама по себе, то может быть также есть смысл для инкапсуляции логики. У вас может даже быть более тонкий разрыв, когда определенные решения принимаются в одном месте, а другие - в другом месте - возможными примерами этого являются триггеры.
• Управляемость: логика в коде приложения - гораздо лучшая поддержка тестирования и т. Д.
• Сложность: (связана с управляемостью) логика в коде приложения.
• Производительность: если объемы данных велики, а использование кода приложения слишком медленное, вы можете быть вынуждены поместить его туда.
• Согласованность: все в коде приложения - и надеюсь, что у вас нет проблем с производительностью. убедитесь, что вы хорошо документируете исключения.

Answer 3

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

Answer 4

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

Во-вторых. SQL - чертовски плохой язык для кодирования сложной логики. Для этого просто нет смысла - одна из причин, по которой SQL Server позволяет писать SP в .NET. Попробуйте вычислить хэш в SQL, и вы поймете, что я имею в виду - все виды строковых манипуляций - это еще одна область. Грязный как черт.

SP в целом довольно часто делаются с идиотскими аргументами. Подобные идиотам аргументы, которые люди приводят, чтобы защитить их, просто не соответствуют действительности. У Франса Бурмы есть список наиболее часто используемых заблуждений и хорошее объяснение, почему аргументы в основном глупые, бессмысленные в http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx - и да, именно этот уровень идиотизма (как люди, которые даже не читают документацию или не думают о том, что они на самом деле говорят, во всех последствиях).

У меня лично есть ограниченные системы с хранимыми процедурами, и у меня есть следующие: ограниченная сложность, но высокая производительность. В основном нет наследования, потому что объектная модель проста, транзакционная логика в SP не слишком сложна, и мне нужна / нужна очень малая скорость блокировки, поэтому некоторые операции перемещаются в хранимые процедуры. Кроме того, это конкретное приложение также имеет очень необычную объектную модель (объекты динамически передаются из разных источников, никогда не обновляются, всегда заменяются, и все изменения ДОЛЖНЫ проходить через службы, а не вноситься в объект - иногда потому, что изменение «запросили» на другом компьютере в другой стране в другой организации.

Хорошим примером является высокопроизводительная система бухгалтерского учета (поскольку она отслеживает сделки из полностью автоматизированных торговых систем). Логика в каждом SP не очень сложна, но я хочу, чтобы SQL работал как можно быстрее.

Теперь, плохие стороны хранимых процедур также очень полезны. Нет правильной среды тестирования, нет поддельных рамок, интеграция с управлением исходным кодом выглядит немного неловко (но выполнимо с правильным набором инструментов). Интегрированная отладка? Что ж, моя огромная благодарность Microsoft и Visual Studio - это действительно работает (точка останова в хранимой процедуре - действительно приятно).

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