buredПо поводу миллиона записей - тут EF не лучшее средство.
На самом деле Include лишь создаёт ключи (референсы) в контексте и не более.
И по поводу asp.net - создайте статический контекст и будет Вам счастье.

WYPMAH, нужно подгружать все свойства по мере надобности, как Вы сказали. Только контекст нужно всегда заново создавать в рамках операции.

buredПо поводу миллиона записей - тут EF не лучшее средство.
Почему?

buredчисто имхо. рано или поздно некий Вася Пупкен (с которыми приходится работать в команде) напишет MyDummyTableForMillionRecords.ToList();
Не, Андрей, такая позиция не канает. Ничто не мешает Васе Пупкину и в классическом ADO.NET написать запрос вида SELECT * FROM MyDummyTableForMillionRecords. Ничто не мешает Васе Пупкину и в хибере написать Session.CreateCriteria<MyDummyTableForMillionRecords>().List()
Так что нельзя говорить о непредназначенности EF к работе с таблицами-миллиониками, оперируя человеческим фактором :)

buredА по поводу создания контекста каждый раз: это конечно хорошее средство от всяких заморочек, но реально видел циферки уваж. дяди, что более 50% времени запроса к базе в EF тратится на создание контекста.
Ну в принципе я тоже не против статика, как Вы порекомендовали (ну или Application)

bured, ну вот, и как после этого можно говорить, что EF плохой, ведь плохой не EF, а Пупкен

buredВот на счёт Application я не понял.
Datacontext не сериализуется. Это известная проблема. Иначе можно было бы таскать контексты по сети. Только если вручную разбирать дерево -> сериализовать -> запихивать в Application и обратно таким же макаром.
Вот Вам классический синглтон контекста:



Вот Вам Application:


buredТак что статик самое оно.
Не самое оно - а как один из вариантов.

buredЛибо как МСУ сказал: создавать новый контекст каждый раз.
Я так делал, но у меня было локальное приложение с одним юзером.
В плане масштабируемости это не айс, конечно. Ибо твёрдо знаю, что создание контекста трудоёмкая операция.
Андрей, что за сказки про трудоемкость? :) Причем тут масштабируемость? :)
Объект DataContext не держит открытым подключение с БД, по большому счету его можно даже и не диспоузить (хотя я всегда уничтожаю объект). Контекст берет подключения из Connection Pool'а тогда при необходимости. Какие тут трудоемкости, о чём Вы говорите?

buredЕщё один случай про Пупкена. Скотт Гу и Джон Папа убились бы. Пупкен одновременно юзал несколько контекстов и периодически таскал внешние ключи туда-сюда. Я блин чуть не поседел с ним.
При чем тут ключи? :)
Покажите пальцем в документ, где Scott Gu рекомендует юзать статик?

buredКороче, EF в неумелых руках превращается в гранату.
Да, вообще, программирование само по себе в неумелых руках превращается в гранату.

bured2. По поводу перфоманса - вот статейка от самих создателей EF. На создание контекста уходит более половины времени.
Шквал запросов к сайту просто положит систему нах.
Спасибо, Андрей, интересная статейка.
Итак, начинаю Вас успокаивать :)
1. В статье ни слова не сказано про половину времени на создание контекста.
2. В статье приведен Warm query results , из которого видно, что на создание контекста затраичвается 1.38% :)
3. Это и нормально, так как на создание экземпляра класса любого более или менее сложного, уйдет не меньше
4. Поймите главное: При создании контекста не происходит Query creation, key kreation, relationship span, материализация и т.д. Это всё произойдет только при выполнении запроса. Что никоим боком не коррелирует с вариантами организации создания контекстов.
5. Итак, создание контекста, - это банальное создание, к примеру, того же SqlConnection (вспомните азы классического ADO.NET - создали коннекцию, отработали с ней, отдиспоузили её). Тут всё тоже самое.

bured3. Про Пупкена: я хз чего он там делал с ключами, но юзать одновременно несколько контекстов не кошерно, мягко говоря.
Вспомните классический ADO, где люди держали открытыи соединения на протяжении всей жизни программы. Сколько клиентов (клиент-сервер), столько и коннектов. И ничего, никто не умирал :)
Ну это я шучу, тут другая немного тема. Юзать много контекстов не то, что не кошерно - а вредно. Речь о другом: можете свободно создавать и удалять контекст при отработке блоков логики. То есть, при каждом обращении к БД создается, отрабатывается и диспоузится контекст. По перфомансу это бить не будет.

P.S. А статейка интересная, благодарю Вас. Внёс в закладки.