Nhibernate Против Entity Framework 4.0

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

В целом я больше склоняюсь к NHibernate, поэтому, когда будете читать эту статью, имейте это в виду.

EF 4.0 устраняет множество проблем, существовавших в предыдущей версии EF. Такие вещи, как прозрачность "ленивая загрузка" , POCO-классы , только код и т. д. EF 4.0 явно намного лучше, чем EF 1.0. Проблема в том, что EF — еще очень молодой продукт. Все изменения, которые были добавлены в 4-ю версию, коснулись лишь поверхности.

Я уже писал о некоторых своих проблемах с моделью.

POCO в EF И Только код , поэтому не буду повторяться.

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

Оба этих случая демонстрируют типичные проблемы, с которыми мы столкнулись в NHibernate и Fluent NHibernate. Эти проблемы были рассмотрены и решены в NHibernate, но появляются в EF. Однако, даже если игнорировать проблемы, которые я обсуждал, есть и другие признаки того, что NHibernate является зрелым продуктом.

Я понял это, когда писал инструкцию для Профилировщик Entity Framework ; есть вещи, которые вы просто не можете сделать с EF, которые являются естественной частью NHibernate. Я не буду пытаться составить подробный список различий.

Мы рассмотрим те случаи, когда между возможностями NHibernate и EF 4.0 есть существенные различия.

В основном это различия в возможности точной настройки того, что делает фреймворк.

Обычно это настройки, позволяющие добиться большей производительности системы без ущерба для использования OR/M. Итак, вот краткий список:

  • Пакетная запись — NHibernate можно настроить для пакетной записи в базу данных; в случае, когда вам нужно выполнить несколько команд записи в базу данных, NHibernate может сделать это за один вызов базы данных вместо доступа к базе данных для каждой команды.

  • Пакетное чтение/множественные запросы/будущие функции — NHibernate может сделать это за один вызов базы данных вместо необходимости обращаться к базе данных для каждой команды.

  • Пакетная загрузка коллекций.

    Когда вы загружаете коллекцию с использованием «отложенной загрузки», NHibernate может найти другие коллекции того же типа, которые не были загружены, и загрузить их все за один вызов базы данных.

    Это отличный способ избежать необходимости ВЫБРАТЬ N+1.

  • Коллекции с «ленивой загрузкой» — Extra Lazy означает, что NHibernate адаптируется к операциям, которые можно запускать поверх коллекции.

    Это означает, что blog.Posts.Count не будет принудительно загружать всю коллекцию, а скорее создаст оператор «select count(*) from Posts, где BlogId = 1», и что также будет выполнен запрос для расчета блога.

    Posts.Contains(), и вся коллекция не будет загружена в память.

  • Фильтры коллекций и коллекции страниц.

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

    Posts без необходимости загружать всю коллекцию в память.

  • Кэш 2-го уровня.

    Как я уже отмечал, управление кэшем представляет собой сложную задачу.

    Почему это важно , поэтому на этот раз я пропущу это.

  • Точная настройка — это то, что имеет решающее значение, когда вам нужно что-то немного выходящее за рамки того, что предоставляет инфраструктура.

    С помощью NHibernate практически во всех случаях можно улучшить существующий фреймворк; с EF вы целиком и полностью заперты.

  • Интеграция и расширяемость — в NHibernate имеется большое количество дополнительных проектов, таких как NHibernate Search, NHibernate Validator, NHibernate Shards и т. д. Для EF таких проектов не только не существует, но и их нельзя написать, поскольку такая возможность просто не предусмотрена.

    для ЭФ.

Однако, с другой стороны:
  • для EF 4.0 существующий поставщик Linq реализован лучше, чем в текущей версии NHibernate. Над этим активно работали в NH 3.0, чтобы исправить этот пробел.

  • EF от Microsoft.
От переводчика: Сам сейчас участвую в небольшом проекте ASP.NET MVC2 + Entity Framework 1.0. OR/M не работал с другими, поэтому сравнение NHibernate и NHibernate стало интересным.

Структура сущности.

Интересно мнение тех, кто тесно сотрудничал и с ОР/М (или с другими) - все ли правильно написал господин Орен Эйни? Есть ли у вас что-нибудь добавить или исправить? Теги: #nhibernate #entity framework 4.0 #.

NET #orm #сравнение #.

NET

Вместе с данным постом часто просматривают: