#база_данных #aspnet #aspnet_mvc #http #веб_программирование
Когда создавать подключение к базе данных?
На каждый запрос к базе
На каждый HTTP-запрос
Глобально в рамках домена - от старта приложения до его смерти
Первые два позволяют локализовать ошибки (обрыв связи с базой покрашит минимум запросов),
обеспечит многопоточную обработку запросов к базе(?) на стороне веб-сервера.
Третий - сократит оверхед на подключениях, особенно если БД вынесена на отдельный
сервер, но лишится плюсов первых двух.
Так что же лучше и в каких случаях стоит применять? Интересно это как по поводу чистого
ADO.NET, так и EF (если под "подключением" мы будем понимать наследника DbContext).
По поводу последнего в туториалах в интернете рассуждают о разнице между п.1 и п.2,
но не п.3. Почему?
Ответы
Ответ 1
Если у программиста возникает такой вопрос, то ему стоит использовать Entity Framework, по тому, что в данном случае фреймворк окажется умнее программиста, который своими попытками оптимизации с наибольшей вероятностью сделает только хуже. Во первых, DbContext, это Unit of Work(как и ISession в NHibernate) Наличие одного DbContext для всего приложения - плохая идея. Единственная ситуация, где это имеет смысл, когда у вас есть однопоточное приложение и база данных, которая используется исключительно этим экземпляром приложения. DbContext не поточно-безопасный, а так же DbContext кэширует данные, по этому вы быстро получите не актуальный кэш. Все это приведет к различным проблемам, когда несколько пользователей/приложений будут работать с этой базой данных одновременно. По этому если у вас не вышеописанная ситуация, то вам лучше инжектить DbContext в каждую задачу. Создавать же контекст на каждый запрос не лучший вариант с точки зрения производительности. Во первых при подключении происходит аутентификация и авторизация, во вторых вы теряете преимущества благодаря кешированию. Другими словами, вам нужно выделять DbContext на каждую бизнес-задачу.
Комментариев нет:
Отправить комментарий