Мы работали и сравнивали, но у Вас слишком общий вопрос.

Попробуйте как-то уточнить, что именно хотели бы знать?

В целом, могу сказать так:
- NHibernate много богаче по возможностям маппинга. Это касается как маппинга сущностей, так и маппинга, чем EF. В частности, в EF сейчас не поддерживаются перечислимые типы, нет custom types, есть только двусторонние ссылки (для нас это означает необходимость менять структуру данных)
- В NH больше возможностей управлять загрузкой из базы. Например, в стандартной поставке EF нет implicite lazy loading (т.е. автоматически, без необходимости вызывать некий метод Load) - хотя есть отдельное решение, которое это делает, нет batch loading. Правда, на сколько это актуально...
- В NH более простая для ручного заполнения структура файла маппинга. EF ориентируется в первую очередь на использование дизайнера.
- В EF нет такого понятие как "кэш второго уровня", т.е. кэшируются только загруженные сущности. Правда, опять таки не уверен, что это плохо, ибо при неправильном использование кэш второго уровня вещь способная привести к очень неприятным последствиям.
- В NH сейчас очень сырая поддержка LINQ, ее обещают доделать к релизу 2.1, но, судя по коммитам в svn и по записям в блогах (где ребята пишут, чем занимаются сейчас) за доделку еще не брались. В EF LINQ очень на высоте, причем есть конструкции, которых банально нет в NH (там это можно сделать только прямым SQL).
- EF это не POCO, хотя все зависимые свойства скрыты как internal или protected.

В целом по ощущениям - EF ближе к СУБД, чем NH. Т.е. получить на первом такого же уровня абстракцию, как на втором - очень не просто. Другое дело, что это дает ощутимый выигрыш в производительности. В целом, на одинаковых запросах EF отстает от прямого DataSet на 10%-20%, тогда как в NH это можно получить только если кэшировать сессию между запросами (что применимо далеко не во всех сценариях).

У EF достаточно интересный roadmap к второй версии - http://blogs.msdn.com/efdesign/archive/2008/06/23/transparency-in-the-design-process.aspx

Если будут какие-то конкретные вопросы спрашивайте, постараюсь ответить

Написал про скорость и понял что поторопился.
Выигрыш на стороне EF в простоых случаях типа получения одного типа сущностей. Однако во всех остальных случаях надо смотреть на тесты - ситуация может быть прямо привоположной.

Я в первом ответе приводил ссылку - это блог программ-менеджера EF.
В самой первой записи он как раз пишет о планах. Планы интересные...

Однако, пока они находятся в роли догоняющих. Причем многие вещи пока отсутсвуют даже в планах.

Кстати, вот один из примеров - я вчера поднял еще раз наши сравнения и понял, что я действительно оочень поторопился написать Вам по поводу выигрыша в скорости в EF. Дело в том, что как только речь заходит о выборке по ссылке many-to-one (т.е. выборке по id), то в NH можно сложить все на кэш (кстати, до сих пор не знаю - первого или второго уровня). А в EF все равно пойдет одиночный запрос к БД.
Понятно, что в общем случае это не показатель, но если это ссылка на небольшой по объему справочник, то через некоторое время он целиком окажется в памяти, а EF будет продолжать ползать в базу...

Так вот, ни о какой поддержке кэщирования во второй версии я ничего не нашел, увы.

acc2003Что сейчас думают товарищи мега-архитекторы-и-все-такое по поводу сравнения родной майкрософтской ORM и лучшей сторонней :)

Я бы сказал, что преимущества пока на стороне NH.
Впрочем, при должной сноровке перейти с NH на EF куда как проще, чем обратно, если в последнем будут серьезные изменения к лучшему.