Имеет ли смысл использовать OR-Mapper?

Question

Имеет ли смысл использовать OR-mapper?

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

Мои рассуждения таковы:

1.) Куда относится SQL?

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

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

2.) Как я могу контролировать генерируемый SQL?Я доверяю деревьям разбора для генерации эффективного SQL.У меня довольно большой опыт оптимизации SQL в SQL-Server и Oracle, но я бы не чувствовал себя обманутым, если бы мне никогда не пришлось делать это снова.:)

3.) Какой смысл использовать OR-Mapper, если я получаю свои данные из хранимых процедур?

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

В течение последних нескольких лет мы все слышали много респектабельных разработчиков, выступающих за использование определенных OR-Mappers (Entity-Framework, NHibernate и т. Д.)...).

Может кто-нибудь сказать мне, почему кто-то должен перейти на ORM для основной разработки крупного проекта?

edit: http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html, похоже, активно обсуждает эту тему, но она устарела.

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

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

Я подозреваю, что основным мотивом для движения ORM является предпочтение разработчика по-прежнему оставаться независимым от настойчивости (не волнует, находятся ли данные в памяти [кроме кэширования] или в базе данных).

ORM, кажется, экономят время для локальных и небольших веб-приложений.

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

Answer 1

Я был профессиональным SP в течение многих, многих лет и думал, что это был ЕДИНСТВЕННО правильный способ разработки БД, но последние 3-4 проекта, которые я сделал, я завершил в EF4.0 без SP и улучшений в моя производительность была действительно впечатляющей - теперь я могу сделать несколько строк кода, которые заняли бы меня за день до этого.

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

Итак, короткий ответ для меня: продуктивность разработчиков является причиной для использования ORM - когда вы все равно преодолеете кривую обучения.

Answer 2

Другой подход ... С появлением движения No SQL сейчас вы можете попробовать использовать базу данных объектов / документов вместо хранения ваших данных. Таким образом, вы в основном избежите ада, который является OR Mapping. Сохраняйте данные по мере того, как ваше приложение использует их, и преобразуйте их за кулисами в рабочем процессе, чтобы переместить их в более реляционный формат / формат OLAP для дальнейшего анализа и составления отчетов.

Answer 3

Следующее - только мое личное мнение, поэтому оно довольно субъективно.

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

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

3.) Работа с объектами как с объектами данных также выгодна по сравнению с прямым доступом к «свободным» наборам данных (даже если они напечатаны). Десериализация набора результатов в граф объектов очень полезна, независимо от того, был ли набор результатов возвращен SP или из динамического запроса SQL.

Если вы используете SQL Server, я приглашаю вас взглянуть на мой проект bsn ModuleStore с открытым исходным кодом, это фреймворк для управления версиями схемы БД и использования SP через некоторую упрощенную концепцию ORM (сериализация) и десериализация объектов при вызове ИП).

Answer 4

Хранимые процедуры отлично подходят для инкапсуляции логики базы данных в одном месте.Я работал над проектом, в котором использовались только хранимые процедуры Oracle, и в настоящее время я использую Hibernate.Мы обнаружили, что разрабатывать избыточные процедуры очень легко, поскольку наши Java-разработчики не разбирались в зависимостях пакетов PL / SQL.

Как администратор проекта, я считаю, что разработчики Java предпочитают хранить все в коде Java.Вы сталкиваетесь с ситуацией: «Почему бы мне просто не пройтись по всем объектам, которые только что вернулись?»Это вызвало ряд "Почему индекс не заботится об этом?"проблемы.

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

Например, у нас есть объект сущности.Можно добавить или изменить задачу среди прочего.Это можно смоделировать в Hibernate Entity в именованных запросах.

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

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