Управление временем жизни dbContext

Ответ 1

Вы можете использовать контейнеры IoC (инверсия управления) для управления временем жизни DBContext, например StructureMap, с помощью следующих шагов:

• Установите пакет nuget для MVC 4: http://nuget.org/packages/StructureMap.MVC4

• Прочитайте быстрый старт: http://docs.structuremap.net/QuickStart.htm

• Задайте область вашего DBC-контекста: http://docs.structuremap.net/Scoping.htm

Также вы можете использовать комбинацию Repository и Pattern of Work Patterns для фиксации или отказа от изменений в группе мутаций в dbcontext по нескольким запросам.

Ответ 2

Этот вопрос отвечает довольно элегантно в следующем сообщении SO:

StructureMap CacheBy InstanceScope.HttpSession не работает

По сути, магия исходит из следующего кода (адаптированного для вашего вопроса и нового синтаксиса для StructureMap):

ObjectFactory.Initialize(factory => {
    factory.For<MyContext>()
           .CacheBy(InstanceScope.HttpSession)
           .Use(new MyContext(_myConnectionString));
});

Затем - в вашем контроллере просто создайте экземпляр объекта, используя:

var db = ObjectFactory.GetInstance<MyContext>();

Поскольку настройка IoC (инверсия управления) с помощью StructureMap настроила экземпляры с областью до HttpSession, вы должны получать один и тот же контекст каждый раз, пока сеанс один и тот же.

Однако помните, что при DbContext объектах, в частности, это обычно очень плохая идея, поскольку вы смешиваете объект отслеживания состояния с безстоящей средой и можете легко попадайте в состояние, когда плохая транзакция или объект, находящийся в нечетном состоянии, может помешать вам выполнять дальнейшие вызовы базы данных до тех пор, пока вы не обновите сеанс.

DbContext объекты, как правило, предназначены для чрезвычайно легкого и одноразового использования. Это вполне нормально, чтобы позволить им выйти из сферы действия и умереть в основном, как только вы закончите с ними.

Ответ 3

Это не очень хорошая игра, чтобы дать DbContext жить с сеансом.

• Когда у вас будет больше запросов, он загрузит часть данных в контекст из базы данных, которая сделает контекст более значительным, что означает проблемы с памятью,

• И у вас не будет обновленных данных по сравнению с DbContet для запроса в контексте, потому что другой пользователь (другой сеанс) может обновить данные, которые вы уже загрузили в контекст.

Кэширование Entity Framework DbContexts для запроса

И прочитайте это для своих опций,

Asp.Net MVC и сеанс

Ответ 4

Обычно в этом сценарии вам необходимо сохранять изменения во временном хранилище (например, сеанс или файл cookie или базу данных). Когда вам нужно сохранить результат или просмотреть новые данные, вы получаете старые данные и изменения и создаете новый объект. Изменения могут быть сохранены как новый объект или последовательность действий. Будьте плотны при применении изменений, может возникнуть конфликт данных. Использование курса Context\Request

Ответ 5

В теории вы можете сохранить контекст в словаре сеанса, доступ к которому вы можете получить в каждом контроллере. Однако у вас может быть проблема с потоками, потому что при ее хранении вы находитесь в другом потоке, чем когда вы его извлекаете. Если контекст не использует threadstatic varaibles, это может сработать (но я не уверен в этом), иначе нет. В любом случае это плохой дизайн... никто в Интернете не делает этого... почему вы хотите сохранить контекст? Вы можете воссоздать его по дешевой цене в последующем http-запросе. Если вам нужно отслеживать изменения свойств, есть другие способы, более подходящие для Интернета.