Это вопрос мне задают очень часто, и я всегда старался уклониться от прямого ответа, но все же меня так часто об этом спрашивают, что я чувствую, что я просто обязан ответить. В общем-то я больше склоняюсь к NHibernate, поэтому, когда вы читаете эту статью, пожалуйста, имейте это в виду.
В EF 4.0 исправлено очень много проблем, существующих в предыдущей версии EF. Такие вещи как прозрачная «lazy loading», POCO классы, code only и т.д. EF 4.0 явно гораздо приятнее чем EF 1.0.
Проблема в том, что EF все еще очень молодой продукт. Все изменения, которые были добавлены в 4 версию лишь коснулись поверхности. Я уже писал о некоторых из моих проблем с моделью POCO в EF и Code Only, поэтому я не буду повторяться. Судя по описанным мной проблемам, основная сложность в том, что между опытом сообщества и тем, что делает Microsoft есть стена. Оба этих случая показывают типичные проблемы, с которыми мы столкнулись в NHibernate и Fluent NHibernate. Эти вопросы были рассмотрены и решены в NHibernate, но появляются в EF.
Тем не менее, даже игнорируя рассмотренные мной проблемы, есть и другие признаки того, что NHibernate зрелый продукт. Я понимал это, когда я писал руководство по Entity Framework Profiler’у; есть вещи, которые вы просто не можете сделать с помощью EF, но которые являются естественной частью NHibernate.
Я не буду пытаться создать список различий по пунктам. Мы рассмотрим те случаи, где есть существенные различия между возможностями NHibernate и EF 4,0. В основном это различия в возможости тонкой настройки того, что делает фреймворк. Как правило, это настройки, позволяющие достигнуть большей производительности системы без ущерба использования OR/M.
Итак, вот небольшой список:
От переводчика: сам в данный момент участвую в небольшом проекте ASP.NET MVC2 + Entity Framework 1.0. С другими OR/M не работал, поэтому стало интересно сравнение NHibernate vs. Entity Framework. Интересно мнение тех, кто плотно работал с обоими OR/M (или другими) — все ли верно написал мистер Oren Eini? есть ли вам что добавить, поправить?
В EF 4.0 исправлено очень много проблем, существующих в предыдущей версии EF. Такие вещи как прозрачная «lazy loading», POCO классы, code only и т.д. EF 4.0 явно гораздо приятнее чем EF 1.0.
Проблема в том, что EF все еще очень молодой продукт. Все изменения, которые были добавлены в 4 версию лишь коснулись поверхности. Я уже писал о некоторых из моих проблем с моделью POCO в EF и Code Only, поэтому я не буду повторяться. Судя по описанным мной проблемам, основная сложность в том, что между опытом сообщества и тем, что делает Microsoft есть стена. Оба этих случая показывают типичные проблемы, с которыми мы столкнулись в NHibernate и Fluent NHibernate. Эти вопросы были рассмотрены и решены в NHibernate, но появляются в EF.
Тем не менее, даже игнорируя рассмотренные мной проблемы, есть и другие признаки того, что NHibernate зрелый продукт. Я понимал это, когда я писал руководство по Entity Framework Profiler’у; есть вещи, которые вы просто не можете сделать с помощью EF, но которые являются естественной частью NHibernate.
Я не буду пытаться создать список различий по пунктам. Мы рассмотрим те случаи, где есть существенные различия между возможностями NHibernate и EF 4,0. В основном это различия в возможости тонкой настройки того, что делает фреймворк. Как правило, это настройки, позволяющие достигнуть большей производительности системы без ущерба использования OR/M.
Итак, вот небольшой список:
- Пакетная запись — NHibernate может быть сконфигурирован для пакетной записи в базу данных; в случае когда вам нужно выполнить несколько команд записи в БД, NHibernate может сделать это за одно обращение к БД, вместо того чтобы обращаться к БД для каждой команды.
- Пакетное чтение/множественные запросы/Future функции — NHibernate может сделать это за одно обращение к БД, вместо того чтобы обращаться к БД для каждой команды.
- Пакетная загрузка коллекций — когда вы загружаете коллекцию с помощью «lazy loading», NHibernate может найти и другие коллекции того же типа, которые не были загружены, и загрузить все за одно обращение к БД. Это отличный способ избежать необходимости SELECT N+1.
- Коллекции с «lazy loading» («экстра») — Extra Lazy означает, что NHibernate адаптируется к операциям, которые можно запустить на верхней части коллекции. Это означает, что blog.Posts.Count не заставит загрузить всю коллекцию, а скорее создаст выражение «select count(*) from Posts where BlogId = 1», и что для вычисления blog.Posts.Contains() будет также выполнен запрос, а не будет произведена загрузку всей коллекции в память.
- Фильтры коллекций и страничные коллекции — это позволяет определить дополнительные фильтры (в том числе разбивку на страницы!) на верхней части вашей коллекции, а это означает, что вы можете легко перемещаться постранично по blog.Posts, и вам не придется загружать всю коллекцию в память.
- Кэш 2-го уровня — управление кэш-памяти является сложной задачей, я уже указывал, почему это важно, так что пропущу это на этот раз.
- Тонкая настройка — это то, что имеет решающее значение, когда вам нужно что-то чуть-чуть сверх того, что обеспечивает фреймворк. С NHibernate, почти во всех случаях, вы можете улучшить существующий фреймворк, с EF — вы полностью и окончательно заблокированы.
- Интеграция и расширяемость — у NHibernate есть большое число дополнительных проектов, таких как NHibernate Search, NHibernate Validator, NHibernate Shards и т.д. Для EF таких проектов не только не существует, но они и не могут быть написаны, потому что для EF просто не предусмотрена такая возможность.
- для EF 4.0 существующий Linq провайдер реализован лучше, чем в текущей версии NHibernate. Это то, над чем активно работали в NH 3.0, чтоб исправить этот пробел.
- EF от Microsoft.
От переводчика: сам в данный момент участвую в небольшом проекте ASP.NET MVC2 + Entity Framework 1.0. С другими OR/M не работал, поэтому стало интересно сравнение NHibernate vs. Entity Framework. Интересно мнение тех, кто плотно работал с обоими OR/M (или другими) — все ли верно написал мистер Oren Eini? есть ли вам что добавить, поправить?
