Enitity Framework и Using
1,00
р.
Подскажите, а является ли нормальной практикой плодить контексты using при работе с Enitity Framework или правильнее передавать объекты сущностей в методы в качестве аргументов?
Вот это я подразумеваю под "Плодить контексты":
DoWork() { using (var db = new Entity()) { // какая-то работа с сущностью ... DoWork2() ... // какая-то работа с сущностью } }
DoWork2() { using (var db = new Entity()) { // какая-то работа с сущностью ... } }
Ответ
У многих, кто использует EF, возникает вопрос, как часто мы должны создавать DbContext, как определить оптимальное время жизни контекста. Возможные варианты времени жизни контекста:
Функция Форма Поток Приложение
Чтобы сделать правильный выбор, предлагаю рассмотреть несколько аспектов:
Правильное разрушение контекста (вызов метода Dispose() контекста) Вызов метода Dispose является важным шагом при работе с классом DbContext. Используя конструкцию using, гарантируетcя своевременный вызов метода Dispose и тем самым освобождение неуправляемых ресурсов. using (MyContext ctx = new MyContext()) { … }
Если забыть вызвать Dispose, то это может привести к утечке открытых соединений к БД и к неосвобождению неуправляемых ресурсов. do-i-have-to-call-dispose-on-dbcontext Стоимость операции создания нового класса контекста Операция создания нового контекста недорогая, потому что это, в основном, копирование ссылок метаданных из глобального кеша. Поэтому за стоимость этой операции не стоит беспокоиться. Использование памяти Чем дольше вы используете объект DbContext, тем больше памяти он занимает. Потому что он будет содержать все сущности (entity), о которых он знает, которые были запрошены через запросы, были добавлены либо присоединены. Поэтому держать долго контекст не рекомендуется. Потокобезопасность Класс DbContext не является потокобезопасным. Если мы используем контекст из нескольких потоков, то мы сами должны обеспечить сихронизацию доступа к контексту. Синхронизация данных с базой данных После создания контекста, если не предпринимать дополнительные меры, контекст не видит изменённые данные в БД, которые были сделаны извне. Создавая новый контекст, меры по синхронизации данных с БД предпринимать не нужно.
Вот основные аспекты, которые пришли в голову. Поэтому контексты с коротким временем жизни при работе с EF являются нормальной практикой и часто используются при работе с EF.
Вот это я подразумеваю под "Плодить контексты":
DoWork() { using (var db = new Entity()) { // какая-то работа с сущностью ... DoWork2() ... // какая-то работа с сущностью } }
DoWork2() { using (var db = new Entity()) { // какая-то работа с сущностью ... } }
Ответ
У многих, кто использует EF, возникает вопрос, как часто мы должны создавать DbContext, как определить оптимальное время жизни контекста. Возможные варианты времени жизни контекста:
Функция Форма Поток Приложение
Чтобы сделать правильный выбор, предлагаю рассмотреть несколько аспектов:
Правильное разрушение контекста (вызов метода Dispose() контекста) Вызов метода Dispose является важным шагом при работе с классом DbContext. Используя конструкцию using, гарантируетcя своевременный вызов метода Dispose и тем самым освобождение неуправляемых ресурсов. using (MyContext ctx = new MyContext()) { … }
Если забыть вызвать Dispose, то это может привести к утечке открытых соединений к БД и к неосвобождению неуправляемых ресурсов. do-i-have-to-call-dispose-on-dbcontext Стоимость операции создания нового класса контекста Операция создания нового контекста недорогая, потому что это, в основном, копирование ссылок метаданных из глобального кеша. Поэтому за стоимость этой операции не стоит беспокоиться. Использование памяти Чем дольше вы используете объект DbContext, тем больше памяти он занимает. Потому что он будет содержать все сущности (entity), о которых он знает, которые были запрошены через запросы, были добавлены либо присоединены. Поэтому держать долго контекст не рекомендуется. Потокобезопасность Класс DbContext не является потокобезопасным. Если мы используем контекст из нескольких потоков, то мы сами должны обеспечить сихронизацию доступа к контексту. Синхронизация данных с базой данных После создания контекста, если не предпринимать дополнительные меры, контекст не видит изменённые данные в БД, которые были сделаны извне. Создавая новый контекст, меры по синхронизации данных с БД предпринимать не нужно.
Вот основные аспекты, которые пришли в голову. Поэтому контексты с коротким временем жизни при работе с EF являются нормальной практикой и часто используются при работе с EF.
