В настоящее время обсуждается, какие плюсы и минусы имеют единую архитектуру соединения sql.SQL CONNECTION лучшие практики
Чтобы уточнить, что мы обсуждаем, при создании приложения открываем соединение sql и при закрытии приложения закрываем или закрываем соединение sql. И не создавать другое соединение вообще, а использовать только тот, чтобы поговорить с БД.
Нам интересно, что думает сообщество.
Закройте соединение, как только оно вам больше не понадобится в течение неопределенного времени. При этом соединение возвращается в пул соединений (если включен пул соединений) и может быть (повторно) использован кем-то другим.
(Соединения - дорогостоящие ресурсы, и иногда они ограничены).
Если вы поддерживаете связь на протяжении всего срока службы приложения, и у вас есть несколько пользователей для этого приложения (таким образом, несколько экземпляров приложения и несколько подключений), и если ваш сервер базы данных ограничен, х количество одновременных соединений, то вы могли бы иметь проблемы ....
Смотрите также best practices for ado.net
Я думаю, что это плохая идея, по нескольким причинам.
Чтобы расширить область 1, вы должны закрыть соединения, как только сможете, потому что в противном случае вы используете конечный ресурс, возможно, в течение неопределенного периода времени. Если у вас был Sql Server, настроенный на максимальное количество подключений до 10 001, вы можете одновременно использовать только 10 001 пользователей. Если вы открываете/закрываете соединения по требованию, то ваше приложение будет масштаб намного дальше, так как вероятность того, что все активные пользователи используют базу данных одновременно, является реалистично низкой.
Под обложками ADO.NET использует пул соединений для управления соединениями с базой данных. Я бы предложил оставить его в пуле соединений, чтобы позаботиться о ваших потребностях в подключении. Сохранение связи на время вашего приложения - плохая идея.
Следуйте этому простому правилу ... Откройте соединение как можно позже и закройте его как можно скорее.
Я использую систему службы поддержки под названием Ричмонд Системы, которые использует одно соединение для жизни приложения, и как пользователь ноутбука, это королевская боль в заднице. Даже когда я переношу свой ноутбук на открытом месте, переходов между точками беспроводного доступа достаточно, чтобы отказаться от совместного использования БД. Затем программное обеспечение жалуется на коннекцию БД, попадает в состояние ошибки и не закрывается. Его нужно убить вручную из диспетчера задач.
Короче говоря, НЕ ХОРОШО ОТКРЫТЬ ПОДКЛЮЧЕНИЕ БАЗЫ ДАННЫХ ДОЛГО, ЧЕМ НЕОБХОДИМО.
Но, с другой стороны, я бы слишком осторожно относился к открытию и закрытию соединений. Это намного дешевле с пулом соединений, чем без, но даже с пулом менеджер пула может решить увеличить или уменьшить пул, превратив его в дорогостоящую операцию.
Мое общее правило заключается в том, чтобы открыть соединение, когда пользователь инициирует какое-либо действие, выполнит работу, а затем закроет соединение, прежде чем ждать следующего ввода пользователя. Для любой данной кнопки «Обновить» нажмите или что-то еще, у меня обычно будет только одно соединение. Но вы определенно не хотите, чтобы соединения открывались во время ожидания ввода пользователя, если вы можете вообще помочь ему по всем причинам, о которых говорили другие. Вы могли буквально дождаться дней до того, как пользователь нажмет другую клавишу или коснется другой кнопки - что, если он покинет свой компьютер и отправится в отпуск? Завязывание ресурса за непредсказуемое количество времени - это плохая новость. В большинстве случаев прошедшее время, ожидающее ввода пользователя, намного превышает время выполнения фактической работы.
Я думаю, это также должно вас заинтересовать: http://valueinjecter.codeplex.com/wikipage?title=Data%20access%20layer%20%28ORM%29%20with%20the%20Value%20Injecter&referringTitle=Home – Omu