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

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

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

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

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

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

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

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

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

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

ORM

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

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

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

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

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

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

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

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

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

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

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

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

ORM

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

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

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

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

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

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