Все здесь прыгают на повозке с ORM?

Я написал уровни доступа к данным, компоненты персистентности и даже свои собственные ORM в сотнях приложений на протяжении многих лет (одно из моих «хобби»); Я даже реализовал свой собственный менеджер бизнес-транзакций (обсуждается в другом месте на SO).

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

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

Используйте базовые концепции модульности, абстракции и инкапсуляции - так что оберните базовый API доступа к данным вашей платформы (например, ADO.NET) собственным слоем, который поднимет уровень абстракции ближе к вашему проблемному пространству. НЕ кодируйте весь свой доступ к данным НЕПОСРЕДСТВЕННО против этого API (также обсуждается в другом месте на SO).

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет. Не все.

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

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

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

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

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

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

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

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

So no.

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

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

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

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

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

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

Я тоже большой поклонник EF и Linq-to-SQL. Мои причины:

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

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

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

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

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

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

1. У вас все еще должен быть запрос в ORM = SQL (SQL намного мощнее)

2. Код сопоставления переходит в конфигурацию, но все еще не устраняется, просто переходит от одной парадигмы к другой.

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

Я что-то упускаю?

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

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

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

Я перешел на LINQ и никогда не оглядывался назад. DBLinq отлично подходит для работы с другими базами данных, кроме MSSQL. Я использовал его с МОИМ SQL, и это ОТЛИЧНО.

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

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

Это не для того, чтобы принижать ORM, LINQ или что-то в этом роде; Я оставляю за собой суждение до

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

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

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

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

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

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

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

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

SQL мертв для меня. Я ненавижу писать это, особенно когда это где-то в моем коде. Ручное написание запросов на выбор / вставку / обновление / удаление для каждого объекта - это пустая трата времени, ИМО. И даже не заставляйте меня обрабатывать NULL («where col_1 =?» Vs «where col_1 is null») при динамической генерации запросов. Инструменты ORM могут справиться с этим за меня.

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

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

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

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

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

Вот одно твердое мнение.

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