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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

ОРМЫ

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

ОРМ

По крайней мере, некоторые ORM допускают сопоставление с хранимыми процедурами

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

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

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

Answer 6

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

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