Использование хранимых процедур как слой бизнес-логики

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

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

Я не могу сказать вам, сколько проектов я выполнял, в которых новый человек приходил на борт и думал, что текущую архитектуру нужно изменить. Я сам так делал несколько раз. Это не самое лучшее место. Статус-кво будет бороться с вами до конца. Если вы действительно настроены на изменение существующей системы, создайте себе авторитет. Через 3-6 месяцев начните предлагать лучшие способы подхода к некоторым из существующих инфраструктур. Если вам действительно не нравится текущая архитектура, уходите из компании".

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

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

Мы делаем это.

Это потому, что мы поддерживаем сценарии, в которых пользователи подключаются к базе данных, используя программы, отличные от предусмотренных (например, SQL Management studio, osql и Excel).

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

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

(я добавил тег «субъективный»)

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

Christopherous 5000: вы все еще можете проводить модульное тестирование с помощью хранимых процедур

Я склонен согласиться с ответами на эти два похожих вопроса:

• Бизнес-логика: уровень базы данных или приложения

• Должен ли уровень доступа к данным содержать бизнес-логика?

Это зависит.

Это зависит от того, что вы называете бизнес-логикой.

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

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

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

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

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

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

Я бы сказал, что хранимые процедуры не так хорошо поддаются модульному тестированию и рефакторингу, как логика бизнес-слоя в .net/java. Я бы максимально убрал логику из БД, главным исключением являются операции, основанные на множествах, где СУБД была бы на высоте.

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

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

Если то, что у вас есть, работает, просто подумайте, как работать с этим дальше.