Устойчивость статического класса в приложениях MVC

Question

Я за последние пару месяцев перенаправил свои знания Webforms на знания MVC, и я должен сказать, что, изначально являясь скептиком MVC, я люблю MVC и то, как он работает.

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

Мой первый вопрос: действительно ли это в случае MVC?

Тогда мой второй вопрос о том, где сохранить экземпляр DBContext в моем приложении MVC. В настоящее время у меня это как общедоступная переменная в статическом классе DAL. Затем единый контекст распределяется между всеми клиентами.

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

Есть ли недостаток в наличии контекста в статическом классе?

Answer 1

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

Answer 2

Сохранение одного экземпляра DbContext экземпляра на протяжении всего срока службы приложения для меня не очень хорошо. Обычно я использую один экземпляр DbContext за Request.

После 2 точки, которые вы можете рассмотреть при принятии решения соответствующего срока службы для DbContext в приложении:

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

2. Повторное создание контекста слишком часто с другой стороны также не является , потому что это дорогостоящая операция.

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

Answer 3

DbConext не является потокобезопасным, EF допускает только одну операцию concurrtent в том же контексте. Поэтому не рекомендуется делиться ею между запросами. В большинстве случаев контекст для запроса является лучшим решением. (Подсказка: есть некоторые рамки IoC, такие как autofac, которые могут создавать экземпляры для каждого запроса)