И никакой ложки. Нет, правда, минус есть: производительность. Намного проще оптимизировать запросы к БД, когда вам не нужно проходить через ORM. (Я не жалуюсь - недавно перешедший на ORM, я в основном доволен; для общих целей ORM - это лучший способ; но оставьте способ запускать запросы ближе к металлу, если вам нужна производительность)
Писквор покинул здание
2
@ UğurGümüşhan, ИМХО, главное преимущество использования ORM - сделать разработчиков более продуктивными, позволяя им программировать на том же языке и парадигме объектно-ориентированного программирования, которые они используют в остальной части своего приложения. Хранимые процедуры не могут этого обеспечить, когда они создают код разработчика на языке хранимых процедур СУБД. Таким образом, они не могут делать все, что может ORM.
Билл Карвин
Ответы:
53
Делаем доступ к данным более абстрактным и переносимым. Классы реализации ORM знают, как писать SQL для конкретного поставщика, поэтому вам не нужно.
Хотя я согласен с тем, что это особенность ORM, я бы предположил, что вариант использования довольно ограничен. Я никогда не использовал ничего, кроме MySql и sqlite около десяти лет. Я думаю, что это, наверное, очень редкое требование для большинства разработчиков.
troelskn
40
@troelskn: Я согласен, я использовал много продуктов РСУБД, но не более одного или двух на проект. Так что переносимость - не самое практическое значение абстрагирования SQL. Я думаю, что многие пользователи ORM просто хотят вообще избегать кодирования на SQL.
Билл Карвин,
2
поставщики все время выпускают новые версии / функции ... просто нужно несколько крутых людей, чтобы написать диалект, и это будет легкое обновление!
dotjoe
5
Типичный бесполезный ответ Мне интересно, почему он помечен как хороший ответ, похоже, что парень, который задает вопрос, просто пытается оправдать своего босса, что он должен использовать ORM :) Мой вопрос, скорее всего, заключается в том, с какой проблемой вы столкнетесь с Hibernate stackoverflow.com/questions/6477170/…
user310291
2
@ user310291: OP не спрашивал о проблемах или подводных камнях, он спрашивал о преимуществах использования ORM. Конечно есть плюсы и минусы, но он просил плюсы. Честно говоря, я удивлен, что этот ответ был принят и получил столько голосов, потому что я бы не стал считать его главным преимуществом ORM.
Bill Karwin
83
Самая важная причина использования ORM заключается в том, что вы можете иметь богатую объектно-ориентированную бизнес-модель и при этом иметь возможность хранить ее и быстро писать эффективные запросы к реляционной базе данных. С моей точки зрения, я не вижу каких-либо реальных преимуществ, которые дает вам хороший ORM по сравнению с другими сгенерированными DAL, кроме расширенных типов запросов, которые вы можете написать.
Один из типов запроса, о котором я думаю, - это полиморфный запрос. Простой запрос ORM может выбрать все формы в вашей базе данных. Вы получаете обратно коллекцию фигур. Но каждый экземпляр представляет собой квадрат, круг или прямоугольник в зависимости от своего дискриминатора.
Другой тип запроса - это запрос, который охотно выбирает объект и один или несколько связанных объектов или коллекций за один вызов базы данных. Например, каждый объект формы возвращается с заполненными коллекциями вершин и сторон.
Мне очень жаль, что я не согласен со многими другими здесь, но я не думаю, что генерация кода сама по себе является достаточно хорошей причиной для использования ORM. Вы можете написать или найти много хороших шаблонов DAL для генераторов кода, которые не имеют концептуальных или производственных накладных расходов, как у ORM.
Или, если вы думаете, что вам не нужно знать, как писать хороший SQL, чтобы использовать ORM, я снова не согласен. Возможно, правда, что с точки зрения написания отдельных запросов проще полагаться на ORM. Но с ORM слишком легко создавать плохо работающие процедуры, когда разработчики не понимают, как их запросы работают с ORM и SQL, в которые они переводятся.
Наличие уровня данных, который работает с несколькими базами данных, может быть преимуществом. Однако это не тот, на который мне приходилось так часто полагаться.
В конце концов, я должен повторить, что по моему опыту, если вы не используете более продвинутые функции запросов ORM, есть другие варианты, которые решают оставшиеся проблемы с меньшим обучением и меньшими циклами ЦП.
О да, некоторые разработчики находят работу с ORM увлекательной, поэтому ORM также хороши с точки зрения радости ваших разработчиков. знак равно
Хорошо сказано. Хотя исходный плакат специально искал «за», а не «против», я видел УЖАСНЫЙ SQL, созданный из-за того, что не понимал, как вы используете ORM. Для меня самое большое преимущество - это простые транзакции CRUD, которые составляют большую часть вашего кода DAL для транзакционных систем. Я думаю, что вы разделяете волосы между чистым ORM и другими сгенерированными методами DAL. Я думаю, что все, что помогает вам переводить между объектами и БД, можно рассматривать как ORM, это просто другая операционная модель.
Дуг Лампе
1
@Doug - я думаю, что различие, которое я получил, заключалось в том, что простой DAL состоял немного больше, чем сгенерированный CRUD SQL, тогда как ORM содержал гораздо больше абстракций, таких как свойства навигации, постоянство коллекции, выделенные языки запросов, кеши и т. Д. - Лучший способ Изложение моей точки зрения в свете вашего наблюдения может заключаться в том, что, хотя это правда, что использование большего количества функций ORM позволяет вам реализовать быстрее, ни в коем случае нельзя оставаться в неведении о том, как эти функции работают. Возможно, потому, что абстракции ORM просачиваются больше, чем большинство других. ( En.wikipedia.org/wiki/Leaky_abstraction )
Чак,
пожалуйста, уточните это еще немного: «если вы не используете более продвинутые функции запросов в ORM, есть другие варианты, которые решают оставшиеся проблемы». также, как говорит создатель hibernate Гэвин Кинг: «Действительно, такие системы, как Hibernate, преднамеренно спроектированы как« дырявые абстракции », чтобы при необходимости можно было легко смешивать нативный SQL. Негерметичность абстракции ORM - это особенность, а не ошибка ! " - reddit.com/r/programming/comments/2cnw8x/…
jungle_mole
1) Это старое. Тогда в ORM были все функции (кеширование, запросы, пакетная обработка и т. Д.). IMHO, объектно-ориентированные полиморфные запросы были единственной функцией ORM, которую генерация кода (явное сопоставление ADO) не могла легко предоставить. 2) Хотя некоторые полезные дыры были намеренно оставлены, были также необходимые недостатки и расширенные функции, которые создавали высокую кривую обучения в ORM. Итак, мой ответ заключался в том, чтобы использовать генерацию кода вместо ORM, если вам не нужны сложные запросы. *) В настоящее время в ORM достаточно разнообразия, так что, вероятно, есть подходящий набор функций для вашей команды. Моя команда сейчас увлекается Linq2DB.
Чак
60
Ускоренное развитие. Например, устранение повторяющегося кода, такого как сопоставление полей результатов запроса с элементами объекта и наоборот.
Повторяющийся код - это очень плохо, но не могли бы вы создать абстракцию, которая бы это удалила? Например, у вас может быть объект результатов таблицы / запроса, который будет возвращать вам строки, с которыми вы затем можете что-то делать. Кажется, что ORM разбивают строки на отдельные экземпляры класса, а не на выбранную абстракцию БД, которая представляет собой таблицы / строки результатов запроса. Я не говорю, что это означает, что ORM плохи, но я не уверен, что одно только это является причиной их использования.
Benjohn
@Benjohn, я согласен с тем, что решение ORM обрабатывает отдельные строки как объекты, тогда как СУБД рассматривает наборы строк как объект. Есть вещи, которые вы можете делать в образе мышления РСУБД, чего не можете делать в мышлении объектно-ориентированного программирования.
Билл Карвин
Это похоже на покупку целой машины только для того, чтобы использовать багажник, есть много способов избежать повторяющейся работы
мохас
15
Поддержка объектно-ориентированной инкапсуляции бизнес-правил на уровне доступа к данным. Вы можете писать (и отлаживать) бизнес-правила на предпочитаемом языке приложения, а не на громоздких языках триггеров и хранимых процедур.
Разве вы не хотите, чтобы ваши бизнес-правила были в базе данных? Это преимущество базы данных, верно: несколько клиентов могут использовать один и тот же интерфейс, предоставляемый СУБД. Если большая часть логики вашего интерфейса заблокирована в коде ORM конкретного клиента, значит, ее нет в базе данных, и другие клиенты ее не используют. Подсказка о перерывах в работе бэк-офиса фронт-офиса (модель одного клиента не соответствует модели другого).
Benjohn
1
@Benjohn, я стараюсь помещать в базу данных просто бизнес-правила, но более сложные правила нелегко сформировать в декларативных ограничениях. Например, «покупатель получает скидку 10% на весь заказ при первой покупке более трех пар брюк одного и того же бренда». Как бы вы поместили это бизнес-правило в базу данных (помните, что ответ, связанный с хранимыми процедурами, неуклюж).
Билл Карвин
Сейчас 2020 год, я больше не вижу никого, кто использует хранимые процедуры. Так ты по-прежнему указываешь?
ospider
Я думаю, что моя точка зрения состоит в том, что люди не используют хранимые процедуры, они используют код приложения. Вы что-то другое поняли?
Билл Карвин,
10
Создание шаблонного кода для основных операций CRUD. Некоторые структуры ORM могут напрямую проверять метаданные базы данных, читать файлы сопоставления метаданных или использовать декларативные свойства класса.
За 30 с лишним лет работы с базами данных мне ни разу не приходилось это делать.
HLGEM 01
4
Это не значит, что это невозможно! :)
Мэтт Фенелон
2
@HLGEM означает, что вы закрываете выбор для клиента. Это действительно могло произойти, всего за 3 года работы веб-приложений мы создали портативное программное обеспечение с использованием ORM
Альфабраво
1
Вы можете найти это полезным, если хотите запустить тесты в базе данных в памяти
Карлос Паррага
Возможно, что несколько экземпляров одного и того же программного обеспечения могут использовать разные базы данных. Но на самом деле перенос существующих данных из одной программы БД в другую случается редко. И когда это происходит, многие ORM фактически не помогают вам в этом.
jlh
4
Чтобы ваша объектная модель и модель сохраняемости совпадали.
Может быть, чтобы ваша настойчивость была прозрачна для вашей объектной модели,
С.Лотт,
4
Развитие счастья, ИМО. ORM абстрагирует от многих вещей, которые вам нужно делать в SQL. Это упрощает вашу базу кода: меньшее количество исходных файлов для управления и изменения схемы не требуют многочасового обслуживания.
В настоящее время я использую ORM, и это ускорило мое развитие.
Причина, по которой я изучаю это, заключается в том, чтобы избежать сгенерированного кода из инструментов VS2005 DAL (сопоставление схемы, TableAdapters).
DAL / BLL, который я создал более года назад, работал нормально (для того, для чего я его создал), пока кто-то другой не начал использовать его, чтобы воспользоваться некоторыми из сгенерированных функций (о которых я понятия не имел)
Похоже, это обеспечит гораздо более интуитивно понятное и чистое решение, чем решение DAL / BLL с http://wwww.asp.net
Я думал о создании собственного генератора кода SQL Command C # DAL, но ORM выглядит более элегантным решением.
По мере совершенствования инструментария для ORM становится легче определять правильность ваших запросов быстрее с помощью ошибок времени компиляции и тестов.
Составление запросов помогает разработчикам быстрее находить ошибки. Правильно? Правильно. Эта компиляция стала возможной, потому что разработчики теперь пишут запросы в коде, используя свои бизнес-объекты или модели, а не просто строки SQL или SQL-подобных операторов.
При использовании правильных шаблонов доступа к данным в .NET легко выполнить модульное тестирование логики запроса в отношении коллекций памяти. Это ускоряет выполнение ваших тестов, потому что вам не нужно обращаться к базе данных, настраивать данные в базе данных или даже запускать полноценный контекст данных. [РЕДАКТИРОВАТЬ] Это не так верно, как я думал, что это было как unit тестирование памяти может вызвать трудности, которые необходимо преодолеть. Но мне по-прежнему легче писать эти интеграционные тесты, чем в предыдущие годы. [/ EDIT]
Это определенно более актуально сегодня, чем несколько лет назад, когда был задан вопрос, но это может быть только в случае Visual Studio и Entity Framework, в которых заключен мой опыт. Если возможно, подключите свою собственную среду.
Я думаю, здесь есть много хороших моментов (переносимость, простота разработки / обслуживания, акцент на бизнес-моделирование объектно-ориентированного программирования и т. Д.), Но когда вы пытаетесь убедить вашего клиента или руководство, все сводится к тому, сколько денег вы сэкономите, используя ORM .
Сделайте некоторые оценки для типичных задач (или даже более крупных проектов, которые могут возникнуть), и вы (надеюсь!) Получите несколько аргументов в пользу переключения, которые трудно игнорировать.
Тьфу. Мы использовали Net Tiers в большом коммерческом проекте, и я настоятельно не рекомендую его использовать. Проблема в том, что его нельзя компоновать. Хотите запросить объекты Foo и Bar? Вы не можете писать объединения, вам нужно создавать отдельные запросы для каждого типа объекта, который вы хотите. Это приводит к множеству обращений к базе данных, что может снизить производительность и атомарность. Плохо, плохо, плохо. Держись подальше.
Иуда Габриэль Химанго
0
убедите их, сколько времени / денег вы сэкономите при внесении изменений, и вам не придется переписывать свой SQL, поскольку инструмент ORM сделает это за вас
Я думаю, что один из минусов заключается в том, что ORM понадобится обновить в вашем POJO. в основном связано со схемой, отношением и запросом. поэтому сценарий, в котором вы не должны вносить изменения в объекты модели, может быть вызван тем, что он используется совместно с другими пользователями проекта или ч / б клиентом и сервером. поэтому в таких случаях вам нужно будет разбить его на два уровня, что потребует дополнительных усилий.
Я разработчик Android, и, как вы знаете, мобильные приложения обычно не огромны по размеру, поэтому эти дополнительные усилия по разделению чистой модели и модели, затронутой orm, не кажутся стоящими в полной мере.
Я так понимаю, что этот вопрос общий. но мобильные приложения также входят в общий зонтик.
Ответы:
Делаем доступ к данным более абстрактным и переносимым. Классы реализации ORM знают, как писать SQL для конкретного поставщика, поэтому вам не нужно.
источник
Самая важная причина использования ORM заключается в том, что вы можете иметь богатую объектно-ориентированную бизнес-модель и при этом иметь возможность хранить ее и быстро писать эффективные запросы к реляционной базе данных. С моей точки зрения, я не вижу каких-либо реальных преимуществ, которые дает вам хороший ORM по сравнению с другими сгенерированными DAL, кроме расширенных типов запросов, которые вы можете написать.
Один из типов запроса, о котором я думаю, - это полиморфный запрос. Простой запрос ORM может выбрать все формы в вашей базе данных. Вы получаете обратно коллекцию фигур. Но каждый экземпляр представляет собой квадрат, круг или прямоугольник в зависимости от своего дискриминатора.
Другой тип запроса - это запрос, который охотно выбирает объект и один или несколько связанных объектов или коллекций за один вызов базы данных. Например, каждый объект формы возвращается с заполненными коллекциями вершин и сторон.
Мне очень жаль, что я не согласен со многими другими здесь, но я не думаю, что генерация кода сама по себе является достаточно хорошей причиной для использования ORM. Вы можете написать или найти много хороших шаблонов DAL для генераторов кода, которые не имеют концептуальных или производственных накладных расходов, как у ORM.
Или, если вы думаете, что вам не нужно знать, как писать хороший SQL, чтобы использовать ORM, я снова не согласен. Возможно, правда, что с точки зрения написания отдельных запросов проще полагаться на ORM. Но с ORM слишком легко создавать плохо работающие процедуры, когда разработчики не понимают, как их запросы работают с ORM и SQL, в которые они переводятся.
Наличие уровня данных, который работает с несколькими базами данных, может быть преимуществом. Однако это не тот, на который мне приходилось так часто полагаться.
В конце концов, я должен повторить, что по моему опыту, если вы не используете более продвинутые функции запросов ORM, есть другие варианты, которые решают оставшиеся проблемы с меньшим обучением и меньшими циклами ЦП.
О да, некоторые разработчики находят работу с ORM увлекательной, поэтому ORM также хороши с точки зрения радости ваших разработчиков. знак равно
источник
Ускоренное развитие. Например, устранение повторяющегося кода, такого как сопоставление полей результатов запроса с элементами объекта и наоборот.
источник
Поддержка объектно-ориентированной инкапсуляции бизнес-правил на уровне доступа к данным. Вы можете писать (и отлаживать) бизнес-правила на предпочитаемом языке приложения, а не на громоздких языках триггеров и хранимых процедур.
источник
Создание шаблонного кода для основных операций CRUD. Некоторые структуры ORM могут напрямую проверять метаданные базы данных, читать файлы сопоставления метаданных или использовать декларативные свойства класса.
источник
Вы можете легко перейти к другому программному обеспечению баз данных, потому что вы разрабатываете абстракцию.
источник
Чтобы ваша объектная модель и модель сохраняемости совпадали.
источник
Развитие счастья, ИМО. ORM абстрагирует от многих вещей, которые вам нужно делать в SQL. Это упрощает вашу базу кода: меньшее количество исходных файлов для управления и изменения схемы не требуют многочасового обслуживания.
В настоящее время я использую ORM, и это ускорило мое развитие.
источник
Чтобы свести к минимуму дублирование простых SQL-запросов.
источник
Причина, по которой я изучаю это, заключается в том, чтобы избежать сгенерированного кода из инструментов VS2005 DAL (сопоставление схемы, TableAdapters).
DAL / BLL, который я создал более года назад, работал нормально (для того, для чего я его создал), пока кто-то другой не начал использовать его, чтобы воспользоваться некоторыми из сгенерированных функций (о которых я понятия не имел)
Похоже, это обеспечит гораздо более интуитивно понятное и чистое решение, чем решение DAL / BLL с http://wwww.asp.net
Я думал о создании собственного генератора кода SQL Command C # DAL, но ORM выглядит более элегантным решением.
источник
Составление и тестирование запросов.
По мере совершенствования инструментария для ORM становится легче определять правильность ваших запросов быстрее с помощью ошибок времени компиляции и тестов.
Составление запросов помогает разработчикам быстрее находить ошибки. Правильно? Правильно. Эта компиляция стала возможной, потому что разработчики теперь пишут запросы в коде, используя свои бизнес-объекты или модели, а не просто строки SQL или SQL-подобных операторов.
При использовании правильных шаблонов доступа к данным в .NET легко выполнить модульное тестирование логики запроса в отношении коллекций памяти. Это ускоряет выполнение ваших тестов, потому что вам не нужно обращаться к базе данных, настраивать данные в базе данных или даже запускать полноценный контекст данных. [РЕДАКТИРОВАТЬ] Это не так верно, как я думал, что это было как unit тестирование памяти может вызвать трудности, которые необходимо преодолеть. Но мне по-прежнему легче писать эти интеграционные тесты, чем в предыдущие годы. [/ EDIT]
Это определенно более актуально сегодня, чем несколько лет назад, когда был задан вопрос, но это может быть только в случае Visual Studio и Entity Framework, в которых заключен мой опыт. Если возможно, подключите свою собственную среду.
источник
В 95% случаев абстрагируйте sql, поэтому не всем в команде нужно знать, как писать суперэффективные запросы к базе данных.
источник
Я думаю, здесь есть много хороших моментов (переносимость, простота разработки / обслуживания, акцент на бизнес-моделирование объектно-ориентированного программирования и т. Д.), Но когда вы пытаетесь убедить вашего клиента или руководство, все сводится к тому, сколько денег вы сэкономите, используя ORM .
Сделайте некоторые оценки для типичных задач (или даже более крупных проектов, которые могут возникнуть), и вы (надеюсь!) Получите несколько аргументов в пользу переключения, которые трудно игнорировать.
источник
Уровни .net с использованием шаблонов code smith
http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1
Зачем кодировать то, что также можно сгенерировать.
источник
убедите их, сколько времени / денег вы сэкономите при внесении изменений, и вам не придется переписывать свой SQL, поскольку инструмент ORM сделает это за вас
источник
Я думаю, что один из минусов заключается в том, что ORM понадобится обновить в вашем POJO. в основном связано со схемой, отношением и запросом. поэтому сценарий, в котором вы не должны вносить изменения в объекты модели, может быть вызван тем, что он используется совместно с другими пользователями проекта или ч / б клиентом и сервером. поэтому в таких случаях вам нужно будет разбить его на два уровня, что потребует дополнительных усилий.
Я разработчик Android, и, как вы знаете, мобильные приложения обычно не огромны по размеру, поэтому эти дополнительные усилия по разделению чистой модели и модели, затронутой orm, не кажутся стоящими в полной мере.
Я так понимаю, что этот вопрос общий. но мобильные приложения также входят в общий зонтик.
источник