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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

Сохраненные процедуры

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

ORMs

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

Сохраненные процедуры

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

ОРМ

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

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

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

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

Ответ 6

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

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