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

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

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

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

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

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

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

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

, Как это поможет с доступом DB и безопасностью?

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

, Как это узнает о схеме DB и удостоверениях пользователя?

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

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

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

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

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

Экономит Вам время, так как Вы не должны кодировать часть доступа дб.

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

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

, Как это поможет с доступом DB и безопасностью?

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

, Как это узнает о схеме DB и удостоверениях пользователя?

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

Большинство используемых баз данных является реляционными базами данных, который непосредственно не переводит в объекты. Какой Объектно-реляционный Картопостроитель делает взятие данные, создайте оболочку вокруг этого со служебными функциями для обновления, удаления, вставки и других операций, которые могут быть выполнены. Таким образом вместо того, чтобы думать о нем как о массиве строк, у Вас теперь есть список objets, которым можно управлять, поскольку Вы были бы любой другой, и просто назовите obj. Сохраните (), когда Вы будете сделаны.

я предлагаю, чтобы Вы смотрели на часть ORM's, которая используется, моим фаворитом является ORM, используемый в платформе Python, django. Идея состоит в том, что Вы пишете определение того, как Ваша внешность данных в базе данных и ORM заботится о проверке, проверках и любой механике, которая должна работать, прежде чем данные будут вставлены.

Главные Преимущества:

1. Абстракция Базы данных
2. центральный API менталитет дизайна
3. Высокий уровень == Меньше для волнения о на фундаментальном уровне (его мысль для Вас)

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

я люблю не иметь необходимость волноваться о ВНУТРЕННЕМ ОБЪЕДИНЕНИИ и ИЗБРАННОМ КОЛИЧЕСТВЕ (*). Я просто работаю в своей абстракции высокого уровня, и я заботился об абстракции базы данных одновременно.

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

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

ORMs раздуваются для того, чтобы быть решением проблем Доступа к данным. Лично, используя их в Проекте Предприятия, они далеки от того, чтобы быть решением для Разработки Корпоративного приложения. Возможно, они работают в маленьких проектах. Вот проблемы, которые мы испытали с ними конкретно nHibernate:

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

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

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

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

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

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

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

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

Я не могу говорить за другой ORM's, просто Быть в спящем режиме (для Java).

В спящем режиме, дает мне следующее:

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

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

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

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

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

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

РЕДАКТИРОВАНИЕ: OP прокомментировал в других ответах, что его кодовая база не очень объектно-ориентирована. Контакт с объектным отображением является только одним фасетом ORMs. Активная Запись шаблон является хорошим примером того, как ORMs все еще полезны в сценариях где карта 1:1 объектов к таблицам.

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

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

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