Смешивание хранимых процедур бизнес-логики и ORM

Question

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

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

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

Мы планируем перейти на ASP.NET (WebForms) в ближайшем будущем.

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

Поскольку я хочу иметь возможность использоватьПреимущества объектно-ориентированного программирования, я хочу сопоставить таблицы с реальными классами.Пока что мое решение состоит в том, чтобы использовать ORM (Entity Framework 4 или nHibernate), чтобы избежать сопоставления объектов вручную (в основном для извлечения данных), и использовать какой-либо уровень доступа к данным для вызова существующих хранимых процедур (для сохранения).

Мне нужен ваш совет по этому поводу.Как вы думаете, это хорошее решение?Любые идеи?

Редактировать: Должен ли я просто пойти со стандартным подходом DataTable / DataRow?

Answer 1

По моему мнению

Хранимые процедуры ваши друзья по многим, многим причинам. Я обязываю выполнять все операции с БД в хранимых процессах в моих проектах и ​​блокирую учетную запись приложения на сервере SQL, чтобы разрешить ему только выполнять хранимые процедуры (прямой доступ к таблицам любого вида) отсутствует. Тем не менее, смешивание обновлений / удалений в одном и том же процессе кажется мне плохой практикой (хотя я склонен комбинировать вставку / обновление в одной и той же процедуре).

Обратите внимание: любая логика в хранимых процедурах не должна быть переопределена при переходе от ASP к ASP.NET, поскольку она существует вне веб-кода. +100 баллов за хранение запросов там, где они принадлежат.

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

Смешивание ORM с сохраненными процессами звучит как хороший способ похудеть и поправить волосы в молодом возрасте.

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

Answer 2

Какие преимущества объектно-ориентированного программирования вы ожидаете получить?

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

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

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

Answer 3

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

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

Answer 4

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

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

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