Вот прочитал сейчас введение в Entity Framework у Троелсена.
Вопрос у меня такой - если у меня есть проект, в проекте куча окошек, в каждом окошке осуществляется доступ к различным таблицам (как правило у меня тут одно окно - одна таблица) одной и той же базы данных, то мне при генерации edm-файла указывать сразу все таблицы? Короче говоря, как чаще всего делают - генерят один edm на всё приложение или несколько разных?

имхо один. Вообще вся эта хрень с генерацией настоящий *****ц  на чуть более крупном проекте, чем Hello word. Незря все сейчас молятся на EF CodeFirst - там этот адЬ залит в классы и его особо не видно.

У меня вот есть модель с 400 таблицами... я ее даж отредактировать в дизайнере не могу... так-то.

jonie, у EF есть какие-то серьёзные недостатки? И можно ссылку на этот ваш Code First, чтобы узнать что это, а то я пробил - и вот так вот сразу ничего не нашёл хорошего.

EFCodeFirts еще не вышел, разве что в составе EF Feature CTP5 (будущем EF5).
Серъезный недостаток генератора по умолчанию это генерация сильносвязанных сущностей с DataContext-ом. Это всё невидно когда у вас клиент-серверное приложение, а не классическая 3-х звенка. Но как только вы переходите грань к 3-х звенному программированию, то эта связь начинает начисто ломать принципы SOA.

Да, есть генераторы POCO сущьностей для EF4 (в онлайне найти можно), но у них тоже есть ограничения.

А почему? В чём будет разница? Сразу не пойму.

Ну многие очень людят отождествлять модель и бизнес модель. Модель это то что нам нагенерирует EF, в то время как бизнес модель - это те объекты, которыми мы должны обмениваться между клиентом и сервером (например по WCF).

Если мы не различаем эти понятия, то проброс EF сущностей через например WCF нарушает принципы SOA, т.к. кроме собственно field-ов через сеть будет пробрасываться мета информация о Entity (например ObjectContext).

В общем и целом - проброс по сети EF это плохая идея.

Но готовые классы так манят...

Обычно делают свои классы (DTO) без всякого мусора, которые мапят на EF сущноси и расширяют как надо... это всё, конечно, круто, но приводит к "забавностям". Например у вас есть классика жанра - база вида: служащие-департамент.
Нагенили EF, и сделали DTO классы одноименные.. и везде по коду для проброски данных через WCF передаете  DTO. А потом у вас появляется два заказчика - одному надо чтобы он видел представление пользователя  (строку) в виде "Имя служащего (департамент)", другой же о департаментах ничего знать не должен. Оопс. Нам придется написать ДВА класса DTO "служащий" + два метода WCF возращающего инфу (это придется сделать в силу безопасности)... ну и чем дальше тем сложнее поддерживать этот зоопарк и не забывать к тому же обновлять маппировку в случае изменения базы....

Почему не NHibernate?

потому что вопрос не про него.

а если бы про него был?

А NHibernate принципиально отличается?

К сожалению я не владею вопросом  

Добавлено через 9 минут и 21 секунду
Но говорят, что NHibernate намного более доработан чем EF. Но работу с EF ты удобно ведёшь в дизайнерах VS, а в NHibernate нужно много прописывать вручную в текстовых файлах

насчет "доработан" спорно.... в общем и целом да,сейчас я бы выбрал NH, но чуть  позж, вероятнее всего EGCodeFirest

http://blogs.msdn.com/b/adonet/archive/201...1-released.aspx
Вышел. Почти на 3 недели раньше поста