Что такое лучшие практики на руководящих соединениях с базой данных в.NET?
Относительно лучшей практики для руководящих соединений с базой данных в приложении.NET - я знаю, что в целом это плохо для раздавания объекта соединения.
Однако у меня есть некоторое определенное любопытство:
1. У меня есть два экземпляра бизнес-объектов различных классов, в отношениях отцов и детей (ребенок является частным.), Какое из следующего является лучшим?
Сохраните одно частное статическое соединение открытым и совместно использованным, используемым обоими объектами и оставленным открытым, пока родитель не будет расположен.
Сохраните два частных статических соединения открытыми, один для каждого объекта, чтобы не быть закрытыми, пока объект не будет расположен.
Не сохраняйте статические соединения; откройте и впоследствии закройте новое соединение для каждого метода, который требует его. Однако большинство моих методов только выполняет 1-3 запроса, таким образом, это кажется неэффективным...?
2. Моим вторым вопросом является по существу то же, но для единственной формы. Что является лучшим здесь?
Сохраните одно частное статическое соединение открытым и совместно использованным в течение времени жизни формы.
Не сохраняйте статическое соединение; откройте и впоследствии закройте соединение для каждого метода в форме, которая требует его (снова, всего 1-3 запроса на метод.)
4 ответа
(Был комментарием) ...
Теоретически вы не должны получать доступ к базе данных из своей бизнес-логики - она должна находиться в отдельном классе доступа к данным. (Скажем, например, в будущем вам нужно будет хранить их в автономном режиме в XML или использовать Oracle вместо SQL Server ... вы не хотите переписывать свою бизнес-логику!)
У ваших бизнес-объектов не должно быть базы данных связанные с ними связи. Соединение должно быть открыто в каком-либо методе фабричного типа DAL, объект должен быть получен / построен, затем соединение закрыто и объект будет возвращен.
Сами бизнес-объекты должны содержать поля и методы бизнес-логики, которые могут вызывать уровень доступа к данным, который должен создавать новое соединение с базой данных для каждого метода DAL.
Ваши опасения относительно неэффективности можно развеять, используя пул соединений. Это означает, что если вы открываете и закрываете соединение сотни раз, скорее всего, все они будут использовать одно и то же. Но вы вообще не должны поддерживать соединения с базой данных, особенно в качестве членов класса.
Надеюсь, это поможет!
Насколько я понимаю, соединения должны оставаться открытыми только до тех пор, пока это необходимо. В большинстве случаев я видел связи в выражениях Using, подобных
using (DBConnection db = new DBConnection(connectString))
{
//do stuff
}
В ответ на оба вопроса, если вы используете что-то, что имеет пул соединений, например ADO.NET, вы должны закодировать свои запросы, чтобы соединение оставалось открытым как можно короче . Т.е. открывать и впоследствии закрывать новое соединение для каждого метода, который этого требует. . Когда вы закрываете соединение, оно будет возвращено в пул соединений и повторно использовано в следующем запросе, и, таким образом, вы не понесете потери производительности, открывая и закрывая группу соединений. Преимущество состоит в том, что вы не рискуете утечь соединения, которые вы забыли закрыть, и в долгосрочной перспективе у вас будет меньше одновременных открытых соединений, чем если бы вы держали соединения открытыми в течение длительных периодов времени. Не имеет значения, является ли приложение формой Windows или веб-формой: держите соединения открытыми как можно короче.
Эта ссылка может быть полезна: Best Practices for Using ADO.NET
Вот интересная выдержка.
Для лучшей производительности держите соединения к базе данных открытыми только тогда, когда когда это необходимо. Кроме того, уменьшите количество раз, когда вы открываете и закрываете соединение для выполнения нескольких операций.
Я всегда придерживался практики открытия соединений в блоке using, так что метод Dispose (и, следовательно, метод Close) всегда вызывается без моего беспокойства об этом. Используя этот подход, я никогда не сталкивался с ситуацией, когда низкая производительность была связана либо с чрезмерным количеством одновременных соединений, либо с чрезмерным количеством операций установки и разрыва соединений.