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