Почему вы должны использовать ORM? [закрыто]

Если вас мотивируют «за» ORM и почему вы должны использовать 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, не кажутся стоящими в полной мере.

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