Генераторы кода против ORM против хранимых процедур

Question

В каких доменах каждая из этих архитектур программного обеспечения светит или терпит неудачу?

Какие ключевые требования побудят вас выбрать одно из других?

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

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

Answer 1

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

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

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

• ORM идеально подходят для инструментов интеграции, где вам может потребоваться иметь дело с различными СУБД и схемами в зависимости от установки. Измените одну карту, и ваше приложение перейдет от работы с PeopleSoft на Oracle к работе с Microsoft Dynamics на SQL Server.

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

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

Answer 2

Я добавлю два моих цента:

Хранимые процедуры

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

ORMs

• Позвольте вам сосредоточиться только на предметной области и иметь более «чистый» объектно-ориентированный подход к разработке
• Сияйте, когда ваше приложение должно быть кросс-совместимым с БД
• Блеск, когда ваше приложение в основном определяется поведением, а не данными

Генераторы кода

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

Answer 3

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

Пожалуйста, посмотрите эти два других сообщения по теме (динамический SQL против хранимые процедуры против ORM) для получения дополнительной информации

Динамический SQL против хранимых процедур
Что лучше: специальные запросы или хранимые процедуры?

ORM против хранимых процедур
Почему параметризованный SQL генерируется NHibernate так же быстро, как хранимая процедура?

Answer 4

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

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

Единственного правильного ответа не существует, но я больше склоняюсь к стороне ORM, потому что считаю, что имеет больше смысла думать с объектно-ориентированным мышлением.

Answer 5

Вы забыли важную опцию, которая заслуживает отдельной категории: гибридную среду отображения данных, такую ​​как iBatis .

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

Answer 6

Хранимые процедуры

• Плюсы: Инкапсулирует код доступа к данным и не зависит от приложения
• Минусы: Может быть специфичной для СУРБД и увеличивать время разработки

ORM

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

• Плюсы: Абстрагирует код доступа к данным и позволяет объектным объектам записываться в зависимости от домена
• Минусы: Возможные потери производительности и ограниченные возможности картирования

Генерация кода

• Плюсы: Может использоваться для генерации кода на основе хранимых процедур или ORM или их комбинации
• Минусы: Может потребоваться поддержка уровня генератора кода в дополнение к пониманию сгенерированного кода