Narzędzia projektowania połączeń ADO

Narzędzia projektowania połączeń ADO.NET
Aby aplikacja mogła uzyskać dostęp do źródła danych, należy utworzyć odpowiednie połączenie z tym źródłem.
Uwaga Obiekty DataAdapter, Connection, Command oraz DataReader to komponenty tworzące zarządzanych
dostawców danych .NET Framework. Microsoft oraz inne firmy mogą udostępnić innych dostawców danych
.NET, pozwalających na integrację z Visual Studio. Więcej informacji na temat dostawców danych .NET
Framework można znaleźć w artykule Dostawcy danych .NET Framework.
Do tworzenia i zarządzania połączeniami ze źródłami danych w ADO.NET służą obiekty Connection:

SqlConnection — zarządza połączeniami z bazami danych SQL Server w wersji 7.0 lub nowszej. Dzięki
(między innymi) pominięciu warstwy OLE DB jest zoptymalizowany do pracy z bazami SQL Server w wersji
7.0 lub nowszej.

OleDbConnection — zarządza połączeniami ze źródłami danych, dostępnymi poprzez OLE DB.

OdbcConnection — zarządza połączeniami ze źródłami danych, dostępnymi za pośrednictwem ODBC.
Tworzony na podstawie łańcucha połączenia lub nazwy źródła danych ODBC (Data Source Name — DSN).

OracleConnection — zarządza połączeniami z bazami Oracle.
Łańcuchy połączenia
Wszystkie obiekty Connection posiadają podobne składowe, jednak dostępność niektórych składowych obiektu
OleDbConnection zależy od rodzaju źródła danych, do którego obiekt ten jest przyłączony. Istnieją źródła
danych, które nie obsługują niektórych składowych klasy OleDbConnection.
Najważniejszą właściwością obiektu Connection jest właściwość ConnectionString, która zawiera łańcuch
znaków składający się z par atrybut-wartość, zawierających informacje wymagane do zalogowania się do bazy
danych i wybrania właściwej bazy. Typowa wartość właściwości ConnectionString ma następującą postać:
Provider=SQLOLEDB.1;Data Source=MySQLServer;Initial
Catalog=NORTHWIND;Integrated Security=SSPI
Przedstawiony w przykładzie łańcuch połączenia określa, że do komunikacji z bazą danych używane będą
zintegrowane zabezpieczenia Windows (uwierzytelnianie NT). Łańcuch połączenia może także zawierać nazwę
i hasło użytkownika, jednak stosowanie takiego rozwiązania nie jest zalecane, ponieważ atrybuty te zostają
w postaci jawnej umieszczone w skompilowanej wersji aplikacji, co stanowi potencjalne zagrożenie dla
bezpieczeństwa systemu. Więcej informacji na ten temat można znaleźć w artykule Uprawnienia dostępu do
aplikacji internetowych i Model zabezpieczeń.
Uwaga dotycząca bezpieczeństwa Przechowywanie parametrów połączenia (takich jak nazwa serwera,
nazwa użytkownika i hasło) może mieć wpływ na bezpieczeństwo aplikacji. Stosowanie zintegrowanych
zabezpieczeń Windows jest o wiele bezpieczniejszym rozwiązaniem kontroli dostępu do bazy danych. Więcej
informacji znaleźć można w artykule Bezpieczeństwo baz danych.
Najbardziej popularne pary atrybut-wartość, stosowane w OLE DB, są także dostępne w postaci indywidualnych
właściwości — na przykład DataSource lub Database. W czasie pracy z obiektem Connection, parametry
połączenia można ustawić albo przypisując pojedynczy ciąg znaków do właściwości ConnectionString, albo
ustawiając indywidualne właściwości obiektu Connection. Jeśli używane źródło danych wymaga podania
parametru połączenia, który nie jest dostępny w postaci indywidualnej właściwości, konieczne jest użycie
pierwszej metody. We właściwości ConnectionString można także podać ścieżkę do pliku Microsoft Data Link
(.udl). Więcej informacji na temat tych plików można znaleźć w dokumencie Wprowadzenie do Data Link API.
Uwaga
Obiekt SQLConnection nie obsługuje i nie pozwala na podanie atrybutu Provider.
Otwieranie i zamykanie połączeń
Dwie najważniejsze metody obiektu Connection to Open i Close. Metoda Open na podstawie informacji
zawartych we właściwości ConnectionString kontaktuje się ze źródłem danych i otwiera połączenie. Metoda
Close zamyka otwarte połączenie. Zamykanie połączeń jest bardzo ważne, ponieważ większość źródeł danych
może obsłużyć tylko ograniczoną liczbę połączeń, a otwarte połączenia zajmują cenne zasoby systemowe.
Działanie z obiektami DataAdapter i Command nie wymaga ręcznego otwierania i zamykania połączeń. Gdy
wywołujemy jakąś metodę tych obiektów (na przykład metody Fill lub Update obiektu DataAdapter), metoda
ta sprawdza, czy połączenie jest już otwarte. Jeśli nie, otwiera połączenie, wykonuje swoje zadanie i ponownie
zamyka połączenie.
Metody takie jak Fill otwierają połączenie automatycznie tylko wtedy, gdy nie zostało ono jeszcze otwarte. Jeśli
połączenie jest już otwarte, zostanie użyte przez metodę i pozostanie otwarte po zakończeniu działania metody.
Daje to możliwość ręcznego otwierania i zamykania połączeń. Taka możliwość przydatna jest wtedy, gdy mamy
wiele obiektów DataAdapter, które korzystają z tego samego źródła danych. W takim przypadku ciągłe
otwieranie i zamykanie połączenia przy każdym wywołaniu metody Fill jest nieefektywne. Lepszym
rozwiązaniem jest otwarcie połączenia, wywołanie metod Fill wszystkich obiektów DataAdapter i zamknięcie
połączenia.
Pule połączeń
Różni użytkownicy aplikacji często korzystają z bazy danych w taki sam sposób. Na przykład w aplikacjach
internetowych ASP.NET wielu użytkowników może pobierać te same dane z tej samej bazy danych. W takich
przypadkach można podnieść wydajność aplikacji poprzez współdzielenie połączeń z bazą danych (utworzenie
„puli” połączeń). Narzut na otwieranie i zamykanie osobnego połączenia dla każdego użytkownika może
znacznie spowolnić działanie aplikacji.
W obiektach OleDbConnection, OdbcConnection oraz OracleConnection pule połączeń są obsługiwane
automatycznie przez dostawcę danych, tak więc nie trzeba zarządzać nimi własnoręcznie.
W klasie SqlConnection zarządzanie pulami także odbywa się niejawnie, ale dostawca danych umożliwia
również własnoręczne zarządzanie połączeniami. Więcej informacji można znaleźć w artykule Pule połączeń
w dostawcy danych platformy .NET Framework dla SQL Server.
Transakcje
Obiekty Connection pozwalają na obsługuję transakcji z wykorzystaniem metody BeginTransaction, która
tworzy obiekt transakcji (na przykład obiekt SqlTransaction). Obiekt transakcji udostępnia metody, które
pozwalają potwierdzić lub wycofać transakcję.
Zarządzanie transakcjami odbywa się z poziomu kodu aplikacji. Więcej informacji można znaleźć w artykule
Obsługa transakcji.
Konfigurowalne właściwości połączeń
W przypadku większości aplikacji, na etapie projektowania nie da się przewidzieć parametrów połączenia. Jest
to prawdą dla wszystkich aplikacji przeznaczonych dla większej grupy odbiorców — w czasie projektowania
aplikacji nie da się określić parametrów takich jak nazwa serwera bazy danych.
Właśnie dlatego łańcuchy połączeń często definiowane są jako właściwości dynamiczne. Ponieważ właściwości
dynamiczne przechowywane są w pliku konfiguracyjnym (kompilator nie umieszcza ich w plikach
wykonywalnych aplikacji), mogą być zmieniane bez ponownego kompilowania aplikacji.
Najczęściej stosowanym rozwiązaniem jest zdefiniowanie parametrów połączenia jako właściwości
dynamicznych i zapewnienie użytkownikom możliwości ustawienia w pliku konfiguracyjnym parametrów
połączenia (za pomocą małej aplikacji Windows Forms lub Web Forms). Mechanizm obsługi właściwości
dynamicznych w .NET Framework automatycznie pobiera wartości właściwości z pliku konfiguracyjnego i — jeśli
właściwość zostanie zmodyfikowana — zapisuje tam nowe wartości.
Parametry połączeń a bezpieczeństwo
Otwarcie połączenia umożliwia dostęp do ważnego zasobu, jakim jest baza danych, dlatego z konfiguracją
i używaniem połączeń często wiążą się problemy dotyczące bezpieczeństwa.
Sposób zabezpieczenia aplikacji i jej dostępu do źródła danych zależy od architektury systemu. Na przykład
użytkownicy aplikacji internetowych zwykle korzystają z uwierzytelniania anonimowego, zapewnianego przez
internetowe usługi informacyjne (IIS) i nie przedstawiają żadnych poświadczeń tożsamości. W takich
przypadkach aplikacja do otwierania połączeń i do dostępu do baz danych stosuje własne poświadczenia
zamiast poświadczeń użytkowników.
Uwaga dotycząca bezpieczeństwa Przechowywanie parametrów połączenia (takich jak nazwa serwera,
nazwa użytkownika i hasło) może mieć wpływ na bezpieczeństwo aplikacji. Stosowanie zintegrowanych
zabezpieczeń Windows jest o wiele bezpieczniejszym rozwiązaniem kontroli dostępu do bazy danych. Więcej
informacji znaleźć można w artykule Bezpieczeństwo baz danych.
Pliki binarne aplikacji internetowych ASP.NET oraz pliki konfiguracyjne są zabezpieczone przed dostępem
z Internetu poprzez wbudowany w ASP.NET model zabezpieczeń, który uniemożliwia dostęp do tych plików za
pośrednictwem protokołów internetowych (HTTP, FTP i tym podobne). Aby zablokować inne metody dostępu do
serwera internetowego (na przykład z wewnętrznej sieci firmy), należy użyć funkcji zabezpieczeń dostępnych
w systemie Windows.
W przypadku aplikacji intranetowych lub aplikacji dwuwarstwowych, można rozważyć użycie uwierzytelniania
zintegrowanego, obsługiwanego przez Windows, IIS i SQL Server. W takim modelu poświadczenia tożsamości,
wykorzystywane do logowania do sieci lokalnej, stosowane są także do uzyskiwania dostępu do bazy danych —
w konfiguracji połączenia nie trzeba jawnie podawać żadnych poświadczeń tożsamości (uprawnienia dostępu do
bazy danych przypisywane są grupom użytkowników, tak więc nie ma potrzeby przypisywania uprawnień
indywidualnym kontom użytkowników). W tym modelu w konfiguracji połączenia w ogóle nie ma informacji
o uwierzytelnianiu, tak więc nie trzeba podejmować dodatkowych działań, mających na celu zabezpieczenie
konfiguracji połączeń do baz danych.
Więcej informacji dotyczących zabezpieczeń można znaleźć w następujących źródłach:

Bezpieczeństwo — najlepsze praktyki

Zabezpieczenia platformy .NET Framework

Uprawnienia dostępu do aplikacji internetowych

Bezpieczeństwo aplikacji internetowych ASP.NET
Połączenia czasu projektowania
Narzędzie Server Explorer umożliwia tworzenie połączeń ze źródłami danych w czasie projektowania aplikacji.
Pozwala to na przeglądanie dostępnych źródeł danych, wyświetlanie informacji o tabelach, kolumnach i innych
elementach, a także na modyfikowanie i tworzenie elementów baz danych.
Połączenia utworzone w ten sposób nie są bezpośrednio wykorzystywane przez aplikację. Informacje uzyskane
za pomocą połączenia czasu projektowania wykorzystywane są do skonfigurowania nowego obiektu połączenia
stosowanego w aplikacji.
Na przykład, rozpoczynając projektowanie aplikacji można użyć narzędzia Server Explorer i utworzyć połączenie
z bazą danych Northwind, znajdującą się na serwerze SQL Server o nazwie MyServer. Następnie w czasie
projektowania formularza można przejrzeć bazę Northwind, wybrać kolumny z tabeli i przeciągnąć je na
projektowany formularz. Spowoduje to dodanie do tego formularza obiektu DataAdapter. Oprócz obiektu
DataAdapter zostanie także utworzony obiekt Connection (jego parametry zostaną ustawione zgodnie
z parametrami połączenia czasu projektowania). Podczas działania aplikacji obiekt ten będzie wykorzystywany
do uzyskania dostępu do bazy danych.
Informacje na temat połączeń czasu projektowania przechowywane są na komputerze lokalnym, niezależnie od
plików projektów i rozwiązań. Po utworzeniu połączenia czasu projektowania jest ono zawsze dostępne
w narzędziu Server Explorer (o ile dostępny jest serwer wskazywany przez to połączenie). Więcej informacji na
temat tworzenia połączeń czasu projektowania w narzędziu Server Explorer można znaleźć w artykule
Tworzenie nowych połączeń w narzędziu Server Explorer.
Uwaga Połączenie utworzone za pomocą narzędzia Server Explorer określa typ obiektów, które zostaną
utworzone podczas przeciągania elementów bazy danych na projektowany formularz. Na przykład, jeśli w czasie
projektowania aplikacji utworzymy połączenie do bazy SQL Server, używając dostawcy OLE DB Provider for
SQL Server, to przeciągnięcie tabeli z narzędzia Server Explorer na okno projektanta spowoduje utworzenie
obiektu SqlConnection. Jeśli aplikacja ma uzyskiwać dostęp do danych za pośrednictwem ODBC, podczas
tworzenia połączenia w narzędziu Server Explorer należy wybrać dostawcę OLE DB Provider for ODBC.
Narzędzia projektowania połączeń w Visual Studio
Podczas pracy w Visual Studio zwykle nie trzeba bezpośrednio tworzyć i zarządzać obiektami Connection. Jeśli
używamy narzędzi takich jak Data Adapter Wizard, kreatory pytają o parametry połączenia (atrybuty zapisane
w łańcuchu połączenia) i automatycznie tworzą obiekty Connection w formularzu lub komponencie, nad którym
obecnie pracujemy.
W razie potrzeby, obiekty Connection do formularza lub komponentu można dodać ręcznie. Sposób ten jest
szczególnie przydatny, jeśli nie stosujemy obiektów DataSet (a zatem nie korzystamy także z obiektów
DataAdapter), a tylko wczytujemy potrzebne nam dane. Własnoręczne tworzenie obiektów Connection
przydatne jest też przy obsłudze transakcji.
Zobacz także (materiały w języku angielskim)
Tworzenie obiektów połączeń w ADO.NET | Połączenie ze źródłem danych za pomocą ADO.NET | Pule połączeń
w dostawcy danych platformy .NET Framework dla SQL Server