Каковы преимущества использования ORM?

Ответ 1

Я бы сказал, что если вы не имеете дело с объектами, мало смысла использовать ORM.

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

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

Если у вас сложный, настроенный вручную SQL, нет смысла использовать ORM.

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

Если у вас есть сложная устаревшая схема, которая не может быть реорганизована, нет смысла использовать ORM.

Итак, здесь обратное:

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

Решения, подобные этим, всегда являются выбором. Выберите, реализуйте, измерьте, оцените.

Ответ 2

ORM раздуваются за то, что они являются решением проблем доступа к данным. Лично, после использования их в Enterprise Project, они далеки от решения для Enterprise Application Development. Возможно, они работают в небольших проектах. Вот проблемы, с которыми мы столкнулись в них: nHibernate:

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

• Пользовательские запросы. Возможность сопоставления пользовательских запросов, не вписывающихся в какой-либо определенный объект, либо не поддерживается, либо не рекомендуется поставщиками инфраструктуры. Разработчики вынуждены находить рабочие места, записывая специальные объекты и запросы или записывая собственный код для получения необходимых им данных. Возможно, им придется регулярно использовать хранимые процедуры для чего-либо более сложного, чем простой Select.

• Связывание с собственностью: для этих фреймворков требуется использование проприетарных библиотек и языков запросов пользовательских объектов, которые не стандартизированы в отрасли компьютерных наук. Эти запатентованные библиотеки и языки запросов связывают приложение с конкретной реализацией провайдера с небольшой или отсутствующей гибкостью для изменения, если это необходимо, и не могут взаимодействовать друг с другом.

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

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

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

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

Для получения дополнительной информации о нашем анализе вы можете прочитать: http://www.orasissoftware.com/driver.aspx?topic=whitepaper

Ответ 3

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

Что он дает мне как разработчику?

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

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

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

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

Как это поможет при доступе к БД и безопасности?

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

Как узнать о схеме БД и учетных данных пользователя?

Многие ORM поставляются с инструментами, которые будут проверять схему и создавать набор классов моделей, которые позволят вам взаимодействовать с объектами в базе данных. [База данных] Пользовательские учетные данные обычно хранятся в файле настроек.

Ответ 4

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

У Oren Eini есть хороший блог, в котором суммируются основные функции, которые могут вам понадобиться в вашем DAL/ORM, и почему он пишет свои собственные, становится плохой идеей после времени: http://ayende.com/Blog/archive/2006/05/12/25ReasonsNotToWriteYourOwnObjectRelationalMapper.aspx

EDIT: OP прокомментировал в других ответах, что его база кода не очень ориентирована на объекты. Работа с сопоставлением объектов - это только один аспект ORM. Шаблон Active Record является хорошим примером того, как ORM все еще полезны в сценариях, где объекты сопоставляют 1:1 с таблицами.

Ответ 5

Я не могу говорить для других ORM, просто Hibernate (для Java).

Hibernate дает мне следующее:

• Автоматически обновляет схему для таблиц производственной системы во время выполнения. Иногда вам все равно придется вручную обновлять некоторые вещи.
• Автоматически создает внешние ключи, которые мешают вам писать плохой код, который создает потерянные данные.
• Реализует объединение пулов. Доступны несколько поставщиков пулов соединений.
• Данные кэширования для быстрого доступа. Доступны несколько поставщиков кэширования. Это также позволяет объединять множество серверов, чтобы помочь вам масштабировать.
• Делает доступ к базе данных более прозрачным, чтобы вы могли легко переносить приложение в другую базу данных.
• Сделать запросы проще для записи. Следующий запрос, который обычно требует, чтобы вы записывали "join" три раза, можно записать следующим образом:
  • "из счета-фактуры i, где i.customer.address.city =?" это извлекает все счета-фактуры с определенным городом.
  • возвращается список объектов-фактур. Затем я могу вызвать invoice.getCustomer(). GetCompanyName(); если данные еще не находятся в кеше, база данных автоматически запрашивается в фоновом режиме.

Вы можете перепроектировать базу данных для создания схемы спящего режима (не пробовал это самостоятельно), или вы можете создать схему с нуля.

Конечно, есть кривая обучения, как с любой новой технологией, но я думаю, что это того стоит.

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

Ответ 6

Лучшие преимущества:

• Абстракция базы данных
• Ориентированный на API дизайн менталитета
• Высокий уровень == Меньше беспокоиться о фундаментальном уровне (о нем думали для вас)

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

Мне нравится не беспокоиться о INNER JOIN и SELECT COUNT (*). Я просто работаю над своей абстракцией на высоком уровне, и одновременно занимаюсь абстракцией базы данных.

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

Ответ 7

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

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

Ответ 8

Лично у меня не было большого опыта использования технологии ORM на сегодняшний день. Я сейчас работаю в компании, которая использует nHibernate, и я действительно не могу с этим справиться. Дайте мне хранимую процедуру и DAL в любой день! Больше кода конечно... но и больше контроля и кода, которые легче отлаживать - из моего опыта использования ранней версии nHibernate он должен быть добавлен.

Ответ 9

Что он дает мне как разработчику?

Экономит ваше время, так как вам не нужно кодировать часть доступа к db.

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

Вы будете использовать либо атрибуты, либо файлы xml, чтобы определить сопоставление классов в таблицах базы данных.

Как это поможет при доступе к БД и безопасности?

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

Как узнать о схеме БД и учетных данных пользователя?

Вы всегда указываете строку подключения. Поставщики инфраструктуры (например, SQL, Oracle, определенные для MySQL классы) предоставляют реализацию, которая запрашивает схему db, обрабатывает сопоставления классов и при необходимости создает/выполняет код доступа db.

Ответ 10

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

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

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

Ответ 11

Для подкаста, который подробно обсуждает ORM, см. следующую ссылку. http://se-radio.net/podcast/2008-12/episode-121-or-mappers-michael-ploed

Ответ 12

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

• Если у вас сложный, настроенный вручную SQL
• Если ваши объекты не имеют отношений 1:1, 1: m или m: n с другими объектами
• Если у вас есть сложная устаревшая схема, которая не может быть реорганизована

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

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

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

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

• jORM
• ActiveJDBC
• ORMLite

Ответ 13

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

nameley, что он устраняет необходимость "заботиться" о том, что происходит на уровне БД. Большинство проблем, которые мы наблюдаем в повседневной работе наших приложений, связаны с проблемами базы данных. Я немного беспокоюсь о мире, который является 100% ORM, что люди не будут знать, какие запросы попадают в базу данных, или если они это делают, они не уверены в том, как их изменить или оптимизировать.

{Я понимаю, что это может быть противоречивым ответом:)}