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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

Вот одно сильное мнение .

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Кроме того, имея 1 место, где SQL может генерироваться динамически, можно надеяться, что это приведет к устранению атак внедрения SQL.

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

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

Answer 6

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

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

Я переключился на LINQ и никогда не оглядывался назад. DBLinq отлично подходит для работы с базами данных, отличными от MSSQL. Я использовал его с моим SQL, и это здорово.

Answer 7

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

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

Это не должно унижать ORM, LINQ или что-то подобное; Я сохраняю суждение до

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

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

Answer 8

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

Answer 9

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