Подключение к базе данных. Когда создавать и сколько ему жить в веб-приложении?

Когда создавать подключение к базе данных?
На каждый запрос к базе На каждый HTTP-запрос Глобально в рамках домена - от старта приложения до его смерти
Первые два позволяют локализовать ошибки (обрыв связи с базой покрашит минимум запросов), обеспечит многопоточную обработку запросов к базе(?) на стороне веб-сервера.
Третий - сократит оверхед на подключениях, особенно если БД вынесена на отдельный сервер, но лишится плюсов первых двух.
Так что же лучше и в каких случаях стоит применять? Интересно это как по поводу чистого ADO.NET, так и EF (если под "подключением" мы будем понимать наследника DbContext). По поводу последнего в туториалах в интернете рассуждают о разнице между п.1 и п.2, но не п.3. Почему?

Ответ

Если у программиста возникает такой вопрос, то ему стоит использовать Entity Framework, по тому, что в данном случае фреймворк окажется умнее программиста, который своими попытками оптимизации с наибольшей вероятностью сделает только хуже.
Во первых, DbContext, это Unit of Work(как и ISession в NHibernate)
Наличие одного DbContext для всего приложения - плохая идея. Единственная ситуация, где это имеет смысл, когда у вас есть однопоточное приложение и база данных, которая используется исключительно этим экземпляром приложения. DbContext не поточно-безопасный, а так же DbContext кэширует данные, по этому вы быстро получите не актуальный кэш. Все это приведет к различным проблемам, когда несколько пользователей/приложений будут работать с этой базой данных одновременно. По этому если у вас не вышеописанная ситуация, то вам лучше инжектить DbContext в каждую задачу. Создавать же контекст на каждый запрос не лучший вариант с точки зрения производительности. Во первых при подключении происходит аутентификация и авторизация, во вторых вы теряете преимущества благодаря кешированию.
Другими словами, вам нужно выделять DbContext на каждую бизнес-задачу.