Все ли здесь прыгают на фургоне ORM?

Ответ 1

На протяжении многих лет я писал уровни доступа к данным, компоненты настойчивости и даже свои собственные ОРМ в сотнях приложений (одно из моих "хобби" ); Я даже реализовал свой собственный менеджер бизнес-транзакций (обсуждаемый в другом месте на SO).

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

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

Используйте основные понятия модульности, абстракции и инкапсуляции, поэтому оберните свой API доступа к базовым данным платформы (например, ADO.NET) своим собственным слоем, который повысит уровень абстракции ближе к вашему проблемному пространству. НЕ СОБЛЮДАЙТЕ весь ваш доступ к данным DIRECTLY против этого API (также обсуждается в другом месте на SO).

Примените принцип DRY (не повторяйте себя) = реорганизовывайте дневной свет из кода доступа к данным. Используйте генерацию кода, когда это необходимо, в качестве средства рефакторинга, но старайтесь устранить необходимость генерации кода всякий раз, когда сможете. Как правило, генерация кода показывает, что в вашей среде что-то отсутствует - недостаток языка, ограниченное ограничение инструмента и т.д.

Тем временем научитесь хорошо использовать доступный API, особенно в отношении производительности и надежности, затем включите эти уроки в свой собственный абстрактный уровень доступа к данным. Например, научитесь правильно использовать параметры в своем SQL, а не встраивать литеральные значения в строки SQL.

Наконец, имейте в виду, что любое приложение/система, которая станет успешной, будет расти, чтобы столкнуться с проблемами производительности. Устранение проблем с производительностью больше зависит от их разработки, а не просто "настройки" чего-то в реализации. Эта работа по дизайну будет влиять на базу данных и приложение, которые должны меняться синхронно. Поэтому старайтесь делать такие изменения легко (гибкими), а не пытаться избежать изменения самого приложения. Частично это в конечном итоге означает возможность развертывания изменений без простоя. Это не сложно сделать, если вы не "отработали" от него.

Ответ 2

Я большой сторонник ORM. Генерация кода с помощью ORM сохраняет мой магазин примерно на 20-30% в большинстве наших проектов.

И мы разрабатываем контракт, так что это большая победа.

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

Кроме того, вы все равно можете полагаться на традиционные sprocs и даже на просмотр, когда это необходимо... Мы не догматически 100% ORM, это точно.

Ответ 3

Я был на поезде ORM в течение самого долгого времени, так как бесплатная версия LLBLGen - самый последний и самый большой коммерческий продукт LLBLGen Pro. Я думаю, что ORM очень хорошо подходят для многих систем вывода данных общего доступа.

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

Ответ 4

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

Оригинальные объектно-ориентированные языки (OO) были связаны с имитацией проблем реального мира с использованием компьютерного языка. Можно утверждать, что, если вы действительно используете язык OO для создания систем, вы будете имитировать реальную область проблем с использованием Domain Driven Design (DDD). Это логично выводит вас на раздел модели проблем, чтобы сохранить DDD в чистоте и прозрачности из-за беспорядка непрерывности данных и управления приложениями.

Когда вы создаете системы после шаблона DDD и используете реляционную базу данных для сохранения, вам действительно нужна хорошая ORM, или вы будете тратить слишком много времени на создание и поддержку базы данных crud (каламбур).

ORM - старая проблема и была решена много лет назад такими продуктами, как Object Lens и Top Link. Объектом объектива была Smalltalk ORM, созданная ParkPlace в 90-х годах. Top Link был создан Object People для Smalltalk, затем преобразован для Java и в настоящее время используется Oracle. Top Link также существует с 90-х годов. Сторонники DDD теперь начинают четко формулировать дело для DDD и получать долю разума. Поэтому ORM по необходимости становится основным, и Microsoft просто реагирует, как обычно.

Ответ 5

Нет. Не все есть.

Здесь номер один большой слон-слон в комнате с большинством инструментов ORM (особенно LINQ to SQL:

Гарантируется, что для ЛЮБОГО изменения, связанного с данными, потребуется полное перераспределение вашего приложения.

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

Ответ 6

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

Мой опыт в том, что он может помочь вам быстро получить версию концептуальной концепции, но может ввести требования рефакторинга, с которыми вы, возможно, не знакомы (по крайней мере пока).

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

Я буду судить (оптимистично) о том, где он будет урегулирован с точки зрения мейнстрима. На данный момент я бы не поставил на него текущий проект. Мои шаблоны для устранения несоответствия импеданса удовлетворительны для моих целей.

Ответ 7

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

Так нет.

Ответ 8

Я с нетерпением жду того дня, когда моя команда начнет искать решения ORM. До этого дня мы являемся чистым магазином DataSet/Storeored Procedure и позвольте мне сказать вам, что не все бисквиты и соус являются "чистыми".

Во-первых, новый Linq to SQL работает близко к хранилищу хранимых обработок и считывателей данных. Мы используем наборы данных везде, поэтому производительность улучшится. До сих пор так хорошо для ORM.

Во-вторых, хранящиеся procs имеют дополнительное преимущество в том, что они выпускаются отдельно от кода, но они также имеют ущерб освобождению от кода. Притворитесь на секунду, что у вас есть база данных с более чем 5 системами, подключающимися к ней, и более 10 человек работают над ней. Теперь подумайте об управлении всеми этими изменениями хранимых процедур и зависимостями, особенно когда есть общая база кода. Это кошмар...

В-третьих, трудно отлаживать хранимые процедуры. Они часто приводят к ошибочному поведению по ряду причин. Это не означает, что то же самое не может быть результатом динамического sql, генерируемого ORM, но одна меньшая проблема - одна проблема. Отсутствие проблем с разрешениями (хотя в основном они разрешены в SQL 2005), не более многоэтапная разработка. Написание запроса, тестирование запроса, развертывание запроса, привязка его к коду, тестирование кода, развертывание кода. Запрос является частью кода, и я считаю это хорошим.

В-четвертых, вы все равно можете использовать хранимые процедуры. Запуск некоторых отчетов, которые занимают много времени? Сохраненные procs - лучшее решение. Зачем? Планы выполнения запросов могут быть оптимизированы с помощью механизма базы данных. Я не буду притворяться, что понимаю все работы базы данных, но я знаю, что есть некоторые ограничения для оптимизации динамического sql в настоящее время, и это компромисс, который мы делаем при работе с ORM. Однако хранимые процедуры не исключаются при использовании решения ORM.

Действительно, самая большая причина, по которой я вижу, что люди избегают ORM, заключается в том, что у них просто нет опыта с одним. Будет очевидная кривая обучения и этап невежества. Однако, если он собирается улучшить производительность разработки и вряд ли затруднит (или в моем случае улучшить) производительность. Это компромисс.

Ответ 9

Я тоже большой поклонник, используя EF и Linq-to-SQL. Мои причины таковы:

Так как LINQ скомпилирован и безопасен, вы не получаете проблем с опечатками в строковом SQL. Я не знаю, сколько часов я потратил на мою жизнь, отслеживая ошибку в SP или другом SQL, где "тик" или другое ключевое слово было не в том месте.

Вышеуказанные и другие факторы ускоряют развитие.

Несмотря на то, что, безусловно, есть накладные расходы по сравнению с методами "ближе к металу" запросов к базе данных, никто из нас не использовал бы .NET вообще или даже С++, если бы производительность была нашей проблемой №1. Для большинства приложений я смог получить отличную производительность от Linq-To-SQL, даже без использования заархивированного подпроцесса (клиентские скомпилированные запросы - это мой обычный подход).

Конечно, для некоторых приложений вы все равно хотите сделать что-то старомодным способом.

Ответ 10

Я предполагаю, что я имел в виду, каково нововведение, которое ORM предоставляют для создания вашего DAL, используя традиционный ADO.NET, SQL и сопоставление их с объектами в коде?

Вот три основных этапа моего DAL, и я сравниваю их с ORM, чтобы увидеть преимущества:

• У вас все еще должен быть запрос в ORM = SQL (SQL более мощный на сегодняшний день)

• Сопоставление кода перемещается в конфигурацию, но все же не устраняется, просто сдвигается от одной парадигмы к другой

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

Я что-то пропустил?

Ответ 11

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

Ответ 12

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

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

Я переключился на LINQ и никогда не оглядывался назад. DBLinq является отличным для выполнения другой базы данных, чем MSSQL. Я использовал его с MY SQL, и он БОЛЬШОЙ.

Ответ 13

пока еще не скептически; как и большинство продуктов microsoft, я жду SP2 или полтора года, прежде чем доверять им в среде producton

и обратите внимание, что почти каждая новая вещь, представленная кем угодно, а не только Microsoft, приветствуется как "легкий, быстрый и простой" - возьмите ее с помощью соли. Они не рекламируют проблемы/проблемы так же громко, как преимущества/функции! Вот почему мы ждем ранних последователей, чтобы их обнаружить.

Это не унижает ORM или LINQ или что-то в этом роде; Я оставляю решение до тех пор, пока

• У меня есть время оценить их,
• возникает необходимость в том, что только они могут удовлетворить,
• технология выглядит стабильной и хорошо поддерживается, чтобы рисковать в одной из производственных сред моих клиентов и/или
• клиент запрашивает его

Обратите внимание: я делал ORM раньше, вручную, и он работал отлично, поэтому я возлагаю большие надежды на новые системы ORM.

Ответ 14

Если codemith генерирует код на основе ваших таблиц, разве вы все еще тесно связаны с вашей схемой данных? Я бы предпочел решение, которое отделяет мои объекты от моей схемы базы данных для большей гибкости в архитектуре

Что из одного из ваших комментариев - это правда, CodeSmith тесно связывает вас с вашими таблицами.

NHibernate, с другой стороны, имеет множество возможностей, которые могут помочь в этом: у вас есть Компоненты, чтобы в коде вы могли: Лицо с адресом свойства, где Address является отдельным классом.

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

Ответ 15

Мы по-прежнему используем ручную, повторяющуюся cut'n'paste DAL, где я работаю. Это очень болезненный, сложный и подверженный ошибкам, но это то, что все разработчики могут понять. Хотя он работает для нас в настоящий момент, я не рекомендую его, так как он начинает быстро ломаться по крупным проектам. Если кто-то не хочет идти на полноразмерный ORM, я бы хотя бы защищал какое-то поколение DAL.

Ответ 16

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

SQL для меня мертв. Я ненавижу писать, особенно имея его в моем коде где угодно. Вручную писать запросы на выбор/вставку/обновление/удаление для каждого объекта является пустой тратой времени IMO. И даже не заставляйте меня начинать с обработки NULL ( "where col_1 =?" Vs "where col_1 is null" ) при динамическом создании запросов. Инструменты ORM могут справиться с этим для меня.

Кроме того, имея 1 место, где SQL может быть динамически сгенерирован, мы надеемся, что долгое время было необходимо устранить атаки SQL-инъекций.

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

Сохранение логической части логики запроса (как правило, как представление или хранимая процедура) также имеет преимущество, доступное для настройки администраторов баз данных. Это была постоянная битва на моей последней работе, используя Hibernate. DBAs: "дайте нам все возможные запросы, чтобы мы могли настроить" Devs ":" Я не знаю, потому что Hibernate будет генерировать их "на лету". Я могу дать вам некоторые HQL и XML-карты! "Администраторы баз данных:" Не заставляйте меня ударить вас в лицо!"

Ответ 17

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

В частности, с отражением .Net, я не вижу необходимости генерировать код для целей ORM.

Ответ 18

Здесь одно сильное мнение.

Ответ 19

Нет, я сбросил ORM и переключился на маленький поток и OODB: Gemstone. Лучший код, меньше кода, более быстрое развитие.