Еще один взгляд на Entity Framework: производительность и подводные камни

Если смотреть в перспективу, то EF выглядит получше.
Microsoft имеет возможность модифицировать язык под фреймворк (ниже покажу на примере Expression Trees).

Прежде всего, в MS думают о юзабилити.
Если у db-класса Entity есть поле int EntityId, оно автоматически становится primary key, без дополнительных подсказок, если есть поле Order Order и поле int OrderId, фреймворк понимает, что OrderId — foreign Key для Order. В отличии от NH, EF не требует описания каждого поля как virtual, а только для lazy-полей.

Я считаю, MS не ввело bulk update именно из-за того, что не придумало обобщённый изящный интерфейс, подходящий одинаково как к SQL, так и к коллекциям в памяти. А лучше ещё подумать, чем выкатить костыль, который из-за совместимости останется надолго во фреймворке.

К слову, если в NH отмапить в одном entity одновременно и Order и OrderId, фреймворк будет падать где-то внутри с исключением «Индекс за пределами коллекции». Мне удалось выявить причину, только подключив исходники NH и подебажив их. Нужно одно из полей пометить как read-only (update=false, insert=false), чтобы можно было работать с таким маппингом.

Запросы в EF строятся через знакомый всем linq, а не с использованием новых классов и новых методов, как в NHibernate (всякие ICriterion, DetachedCriteria, Restrictions и т.п.)
Достаточно написать

context.Orders.Where(order => order.Dealer.Kind == 1 || order.Dealer.Kind == 2)

сравните с NH:

var qOrders = DetachedCriteria.For<Order>();
var qDealer = qOrders.CreateCriteria("Dealer");
qDealer.Add(Restriction.Or(Restriction.Eq("Kind", 1), Restriction.Eq("Kind", 2));
return session.List<Order>(qOrders);

То есть, всё дерево условий строится вручную, а не пишется интуитивно понятными выражениями.

Как видно из предыдущих примеров, NH ссылается на поля через их строковые имена, что противодействует автоматическому рефакторингу и поиску зависимостей. В инете описан велосипед указания полей через лямбду, но из-за reflection он небыстрый.

К слову, ради EF в c# 4.0 ввели expression trees. Например, когда я хочу вызвать функцию получения списка заказов с указанием ключа сортировки в качестве параметра, вызывающий код выглядит как GetMyOrders(order => order.Date). Но это не лямбда (т.е. не Func<Order,object>). Это Expression Tree (тип которого Expression<Func<Order, object>>), парсинг происходит не в runtime, выковыриванием ссылки на поле из кода геттера, а в compile-time.

Ещё о NH. Маппинги описываются в XML-аннотациях. Обычно, каждый entity-класс сопровождается xml-файлом с маппингом. Существует велосипед в community contrib делать маппинги атрибутами, который при запуске проекта рефлектит все классы в указанных сборках, делает XML из атрибутов и скармливает его ORM. Но не все конструкции, выражаемые в XML, можно описать атрибутами (хотя в одном проекте можно совмещать два подхода). В-общем, после NH переход на EF кажется очень приятным.

Плюсом NH отмечу глубочайшую интеграцию с log4net. Если включить максимальный уровень логирования, в десятках мегабайт чтива можно увидеть всё, что происходит под капотом при выполнении небольшой функции. Кроме того, можно включить только логгер SQL, чего я не нашёл в EF (да, в EF любой IQueryable при вызове ToString() обычно даёт SQL, но как одним движениям залогировать все SQL-и, отсылаемые в БД, я не знаю).

Из минусов EF отмечу катастрофичекое падение производительности при большом количестве объектов в контексте. Скорее всего, где-то зарылся небрежный алгоритм с O(N^2). Из-за чего приходится покрывать код, где речь о вставке хотя бы тысячи объектов, костылями типа

context.AutoDetectChangesEnabled = prevEnabledValue;
var prevEnabledValue = context.AutoDetectChangesEnabled;
try { 
    context.AutoDetectChangesEnabled = false;
    ... 
} finally { context.AutoDetectChangesEnabled = prevEnabledValue; }

Есть такой вопрос — а navigation property вообще получается нефункциональная фича?

Почему, очень даже полезная, если работа и правда происходит со всеми элементами коллекции. Т.е. когда загрузка в память желательна — она делается просто. Когда не желательна — да, надо искать другие средства.

var count = context.Threads.Where(e=> e.id == folder.id).Count();

Вы сравниваете Id потока с Id папки — это баг.
Ваш SQL работает для варианта 1 ко многим, а в задаче много ко многим.