Один DbContext на веб-запрос ... почему?

Ни один ответ здесь не отвечает на вопрос. OP не спрашивал об одном дизайне DbContext для одного приложения и для каждого приложения, он задал вопрос о дизайне запроса (web) и о возможных потенциальных преимуществах.

Я буду ссылаться на http://mehdi.me/ambient-dbcontext-in-ef6/, поскольку Мехди - фантастический ресурс:

Возможный прирост производительности.

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

Он обеспечивает ленивую загрузку.

Если ваши службы возвращают постоянные объекты (в отличие от возвращаемых моделей просмотра или других типов DTO), и вы хотели бы воспользоваться ленивой загрузкой этих объектов, время жизни экземпляра DbContext, из которого были получены эти объекты должны выходить за рамки бизнес-транзакции. Если метод службы удалил экземпляр DbContext, который он использовал перед возвратом, любая попытка lazy-load свойств возвращаемых объектов потерпит неудачу (независимо от того, является ли использование ленивой загрузки хорошей идеей, это совсем другая дискуссия, которую мы не будем вдаваться в Вот). В нашем примере веб-приложения ленивая загрузка обычно используется в методах действий контроллера для объектов, возвращаемых отдельным уровнем обслуживания. В этом случае экземпляр DbContext, который использовался сервисным методом для загрузки этих объектов, должен оставаться в живых в течение всего веб-запроса (или, по крайней мере, до завершения действия).

Имейте в виду, что есть и минусы. Эта ссылка содержит много других ресурсов для чтения по этому вопросу.

Просто опубликуйте это, если кто-то другой наткнется на этот вопрос и не будет поглощен ответами, которые на самом деле не затрагивают вопрос.

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

Существуют две противоречивые рекомендации от Microsoft, и многие люди используют DbContexts полностью расходящимся образом.

• Одна рекомендация - "Утилизировать DbContexts как можно скорее" потому что наличие DbContext Alive занимает ценные ресурсы, такие как db соединения и т.д.
• Другое указывает, что Один DbContext для запроса Рекомендуемые

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

Так много людей, которые следуют правилу 1, имеют свои DbContexts в шаблоне репозитория " и создают новый экземпляр для запроса базы данных, поэтому X * DbContext за запрос

Они просто получают свои данные и располагают контекстом как можно скорее. Это считается MANY людьми приемлемой практикой. Хотя это имеет преимущество занять ваши ресурсы в течение минимального времени, он явно жертвует всеми UnitOfWork и кешированием, которые EF может предложить.

Сохранение одного единственного многофункционального экземпляра DbContext максимизирует преимущества Кэширования, но поскольку DbContext не является потокобезопасным, и каждый веб-запрос запускается это собственный поток, DbContext для запроса - это longest, который вы можете сохранить.

Итак, рекомендация команды EF об использовании 1 Db Контекст за запрос явно основана на том факте, что в веб-приложении UnitOfWork скорее всего будет находиться в пределах одного запроса, и этот запрос имеет один поток. Таким образом, один DbContext для запроса похож на идеальное преимущество UnitOfWork и Caching.

Но во многих случаях это неверно. Я считаю Logging отдельный UnitOfWork, поэтому наличие нового DbContext для записи после запроса в асинхронных потоках является полностью приемлемым

Итак, в конце концов, он отключается, что время жизни DbContext ограничено этими двумя параметрами. UnitOfWork и Тема

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

Лично я создаю экземпляры DbContext, когда это необходимо - обычно привязывается к бизнес-компонентам, которые могут воссоздать контекст, если это необходимо. Таким образом, я контролирую этот процесс, вместо того, чтобы навязать мне один экземпляр. Мне также не нужно создавать DbContext при каждом запуске контроллера независимо от того, используется ли он на самом деле. Тогда, если я все еще хочу иметь экземпляры запросов, я могу создать их в CTOR (через DI или вручную) или создать их по мере необходимости в каждом методе контроллера. Лично я обычно использую последний подход, чтобы избежать создания экземпляров DbContext, когда они на самом деле не нужны.

Это зависит от того, с какого угла вы тоже смотрите. Для меня каждый экземпляр запроса никогда не имел смысла. Действительно ли DbContext принадлежит к запросу Http? С точки зрения поведения это неправильное место. Ваши бизнес-компоненты должны создавать ваш контекст, а не запрос Http. Затем вы можете создавать или отбрасывать свои бизнес-компоненты по мере необходимости и никогда не беспокоиться о времени жизни контекста.

Я согласен с предыдущими мнениями. Хорошо, что если вы собираетесь делиться DbContext в приложении с одним потоком, вам потребуется больше памяти. Например, моему веб-приложению на Azure (один дополнительный маленький экземпляр) требуется еще 150 МБ памяти, и у меня около 30 пользователей в час.

Вот реальный пример image: приложение развернуто в 12PM

Что мне нравится в этом, так это то, что он выравнивает единицу работы (как видит пользователь, т.е. страница представляет) с единицей работы в смысле ORM.

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

Еще одна недооцененная причина не использовать одноэлементный DbContext даже в однопоточном однопользовательском приложении из-за шаблона карты идентификации, который он использует. Это означает, что каждый раз, когда вы извлекаете данные с помощью запроса или по id, он будет хранить извлеченные экземпляры сущностей в кеше. В следующий раз, когда вы получите один и тот же объект, он предоставит вам кешированный экземпляр объекта, если он доступен, с любыми изменениями, выполненными вами в одном сеансе. Это необходимо, поэтому метод SaveChanges не может содержать несколько разных экземпляров сущностей одной и той же записи (ов) базы данных; в противном случае контекст должен каким-то образом объединить данные со всех этих экземпляров сущностей.

Причина, по которой возникает проблема, - это одноэлементный DbContext, который может стать бомбой замедленного действия, которая может в конечном итоге кэшировать всю базу данных + накладные расходы на объекты .NET в памяти.

Есть способы обойти это поведение, используя только запросы Linq с помощью метода расширения .NoTracking(). Также в наши дни у ПК много оперативной памяти. Но обычно это не желаемое поведение.

Еще одна проблема, с которой нужно обратить внимание с Entity Framework, - это использовать комбинацию создания новых объектов, ленивую загрузку, а затем использовать эти новые сущности (из того же контекста). Если вы не используете IDbSet.Create(vs only new), Lazy loading на этом объекте не работает, когда его извлекают из контекста, в котором он был создан. Пример:

 public class Foo {
     public string Id {get; set; }
     public string BarId {get; set; }
     // lazy loaded relationship to bar
     public virtual Bar Bar { get; set;}
 }
 var foo = new Foo {
     Id = "foo id"
     BarId = "some existing bar id"
 };
 dbContext.Set<Foo>().Add(foo);
 dbContext.SaveChanges();

 // some other code, using the same context
 var foo = dbContext.Set<Foo>().Find("foo id");
 var barProp = foo.Bar.SomeBarProp; // fails with null reference even though we have BarId set.