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

Question

Microsoft Linq to SQL, Entity Framework (EF), nHibernate и т. Д. Предлагают ORMS в качестве следующего поколения технологий отображения данных и утверждают, что они легкие, быстрые и простые. Как например эта статья, которая только что была опубликована в журнале VS:

http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

Кто все взволнован внедрением этих технологий в свои проекты? Где инновации в этих технологиях, которые делают их такими превосходными по сравнению с предшественниками?

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

Нет. Не каждый такой.

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

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

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

Answer 6

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

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

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

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

Answer 7

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

Так нет.

Answer 8

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

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

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

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

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

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

Answer 9

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

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

1. Вам все еще нужно иметь запрос в ORM = SQL (SQL намного мощнее)

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

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

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

Answer 10

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

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

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

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

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