Добрый день!
Хотелось бы добавить про контексты EF:
stackoverflow.com/questions/9415955/c-sharp-workin...
Поясню: когда я впервые столкнулся с масштабным применением EF, в том проекте использовался класс, в котором в виде поля объявлялся контекст. Т.е. контекст EF существовал все время, пока существовал этот класс (DataService). Так вот: все было хорошо до тех пор, пока не пришлось заняться ускорением работы приложения. И обнаружилось, что такой подход практически не позволяет использовать библиотеку TPL (Task Parallel Library), т.к. постоянно возникали ошибки, связанные с тем, что "контекст уже открыт". Ни в коем случае не используйте контекст EF по паттерну "Одиночка" и в статическом классе - наберетесь больших проблем и замучаетесь исправлять ошибки. Исходя из своего опыта (а также опыта моих коллег и друзей), пока что самым удачным применением EF является (как и написано в статье) использование контекста с коротким жизненным циклом, т.е. написали метод (который, например, получает список городов из БД и который, соответственно, будет внутри слоя доступа к данным), внутри инициализируем контекст (лучше с помощью using), получаем данные, оборачиваем их в модель (если надо), закрываем контекст и возвращаем данные наверх.
P.S. Хотелось бы также порекомендовать Вам НЕ работать с классами, генерируемыми EF, в слое бизнес-логики, а писать для этих классов обертки (модели). В одном из проектов, которыми я занимался, используется WPF + MVVM + IoC (Unity Container), и в нем же весь интерфейс биндится к классам EF... Поверьте, это ужасно. Лучше сразу проектируйте так, чтобы классы EF у Вас использовались
только внутри слоя доступа к данным, а наверху (в бизнес логике) вся работа ведется с классами-обертками над классами EF (т.е. чтобы классы слоя бизнес-логики
ничего не знали о классах EF). В этом еще и такой
плюс, что если Вы по каким-либо причинам решите отказаться от EF и перейти, например, на NHibernate или Native Sql, то все изменения коснутся
только слоя доступа к данным.
