Pamiętaj, że wszystko to w kontekście ekosystemu .Net.
Czasami programiści chcą „zoptymalizować” swój kod, aby ponownie użyć obiektów połączenia. Biorąc pod uwagę kontekst tego pytania, prawie zawsze jest to błąd.
ADO.Net ma funkcję o nazwie Pula połączeń . Kiedy tworzysz i otwierasz nowy obiekt połączenia, tak naprawdę robisz to, żądając połączenia z puli. Po zamknięciu połączenia zwracane jest ono do puli.
Ważne jest, aby zrozumieć obiektów używamy bezpośrednio w kodzie: SqlConnection, MySqlConnection, OleDbConnectio, etc, są tylko owijarki wokół prawdziwego bazowego połączenia zarządzanego przez ADO.Net, a rzeczywiste połączenia ADO.NET są znacznie „cięższy” i droższe z punktu widzenia wydajności. Są to leżące u podstaw obiekty, które mają obawy, takie jak uwierzytelnianie, tranzyt sieci, szyfrowanie i te rzeczy znacznie przewyższają niewielką ilość pamięci w obiekcie, który faktycznie widzisz we własnym kodzie.
Podczas próby ponownego użycia obiektu połączenia przerywa się zdolność ADO.Net do skutecznego zarządzania ważnymi połączeniami bazowymi. Zyskujesz wydajność w małej rzeczy kosztem znacznie większej rzeczy.
Ponowne użycie połączenia w aplikacji lub żądaniu HTTP może również zmusić Cię do przypadkowej serializacji czegoś, co w innym przypadku mogłoby być uruchomione równolegle i stać się wąskim gardłem wydajności. Widziałem to w prawdziwych aplikacjach.
W przypadku przykładu strony internetowej tutaj, gdzie przynajmniej utrzymujesz małe połączenie przez czas trwania pojedynczego żądania / odpowiedzi http, możesz zyskać jeszcze większą wydajność, oceniając, jakie zapytania uruchamiasz w potoku żądań, i spróbuj uzyskać je do jak najmniejszej liczby oddzielnych żądań do bazy danych (wskazówka: możesz przesłać więcej niż jedno zapytanie w jednym ciągu SQL i używać DataReader.NextResult()
lub sprawdzać różne tabele w DataSet
celu przemieszczania się między nimi).
Innymi słowy, zamiast myśleć w kategoriach ponownego wykorzystania jednego połączenia dla aplikacji lub żądania HTTP w porównaniu do jednego połączenia na zapytanie, pomyśl w kategoriach jednego połączenia za każdym razem, gdy wywołujesz bazę danych ... podczas każdej podróży w obie strony. Następnie spróbuj zminimalizować liczbę połączeń, minimalizując liczbę tych podróży. W ten sposób możesz osiągnąć oba cele.
Ale to tylko jeden rodzaj optymalizacji. Istnieje również optymalizacja czasu programisty i efektywne ponowne wykorzystanie kodu. Deweloperzy nie chcą ciągle pisać tego samego kodu, aby uzyskać obiekt połączenia, który jest otwarty i gotowy do użycia. To nie tylko żmudne, to sposób na wprowadzenie błędów w programie.
Jednak nawet tutaj generalnie lepiej jest mieć jedno połączenie na zapytanie (lub w obie strony). Istnieją inne wzorce, których można użyć, aby uniknąć ponownego zapisywania tego samego kodu szablonu. Oto jeden przykład, który mi się podoba, ale jest wiele innych.