ADO.NET w praktyce

ADO.NET to nie tylko kontrolki, które wspomagają konstrukcję interfejsu do interakcji z użytkownikiem, ale także API, które pozwala wykonać wiele operacji na bazach danych. A dzięki temu, że SQL 2005 może uruchamiać kod .NET - własne algorytmy przetwarzania można napisać w ADO.NET, a potem uruchomić najbliżej danych jak to tylko możliwe.

ADO.NET to nie tylko kontrolki, które wspomagają konstrukcję interfejsu do interakcji z użytkownikiem, ale także API, które pozwala wykonać wiele operacji na bazach danych. A dzięki temu, że SQL 2005 może uruchamiać kod .NET - własne algorytmy przetwarzania można napisać w ADO.NET, a potem uruchomić najbliżej danych jak to tylko możliwe.

Mimo że VS.NET 2005 zawiera bardzo dużo mechanizmów ułatwiających pisanie aplikacji bazodanowych, warto się przyjrzeć dokładniej, z czego składa się podstawowe API ADO.NET 2.0 - tym razem bez używania kreatorów (no, prawie bez używania).

W ADO.NET 2.0 dostępne są 4 bliźniaczo podobne interfejsy: do SQL Server 7.0 - 2005 (SqlClient), do baz dostępnych za pośrednictwem ODBC, do baz, dla których mamy sterownik OleDB, oraz do bazy Oracle. Dostępny jest także interfejs SqlClientCe, przeznaczony do SQL CE na platformy Windows CE (PocketPC, SmartPhone itp.).

API przeanalizujemy na przykładzie klienta do SQL - inne biblioteki mają analogiczną strukturę. Na przykład połączenie w SqlClient to SqlConnection. W ODBC nazywa się ODBCConnection, w OleDB - OledbConnection itp. - z bardzo podobnymi metodami. W ten sposób, poznając jedną bibliotekę, zna się strukturę wszystkich.

Podstawowym obiektem, który zapewnia połączenie z bazą danych, jest SqlConnection. W konstruktorze trzeba przekazać specjalny łańcuch, który określa, z jaką bazą i jakim serwerem się łączymy. Zazwyczaj jest on przekazywany jako parametr z pliku konfiguracyjnego. W VS.NET 2005 wystarczy wejść w Properties | Settings.settings danego folderu i łatwo można dodać potrzebne informacje:

Ustawianie parametrów aplikacji.

Ustawianie parametrów aplikacji.

Po wybraniu typu parametru (connection) można w specjalnym oknie wskazać potrzebne parametry. W przypadku SQL najważniejszymi parametrami są:

Data Source - określa nazwę serwera SQL. Może to być adres IP, adres DNS, cokolwiek - co pozwoli znaleźć dany komputer. Jeżeli chcemy się połączyć z konkretną instancją, po nazwie trzeba podać \nazwa instancji (jak w poniższym przykładzie).

Initial Catalog - to nazwa konkretnej bazy danych.

Tworząc łańcuch połączeń, można zdecydować się na logowanie w trybie zintegrowanym (czyli SQL Server używa tego użytkownika, który zalogował się do Windows):

<add name="CustomerEntry.Properties.Settings.TEST1"

connectionString="Data Source=NIEZAPOMINAJKA2\SQL2005; Initial Catalog=Northwind; Integrated Security=True"

providerName="System.Data.SqlClient" />

albo podając hasło i nazwę logowania (Password i User ID):

<add name= "CustomerEntry.Properties.Settings.CnnTEST2"

connectionString="Data Source=NIEZAPOMINAJKA2\SQL2005; Initial Catalog=AdventureWorks; Persist Security Info=True; User ID=sa;Password=atuotwartymtekstemhasło"

providerName="System.Data.SqlClient" />

Definiując taki parametr o nazwie CnnTEST1 w Settings.settings powodujemy, że zostanie wygenerowany odpowiedni wpis w app.config. Proszę zauważyć, że jeżeli używamy logowania SQL, to w pliku konfiguracyjnym jawnie trzeba podać hasło... co zwykle jest złym rozwiązaniem. Lepiej jest używać logowania zintegrowanego.

Gdzie szukać funkcji

W przestrzeni System.Data.Sql znajdują się elementy związane z programowaniem w ADO.NET procedur przechowywanych i funkcji działających w SQL Server 2005.

Baza dostępna bez rejestracji

SqlClient w ADO.NET 2.0 zawiera bardzo ciekawy mechanizm pozwalający połączyć się bezpośrednio z plikiem bazy danych (wskazując odpowiedni na dysku). Co więcej, jeżeli na komputerze mamy zainstalowany SQL Express, można dodać komponent typu SQL Database do projektu np. SampleEmbeddedDB.mdf. Potem można za łańcuch połączeń podać:

Data Source=.\SQLEXPRESS;

AttachDbFilename=E:\SampleEmbeddedDB.mdf;

Integrated Security=True;

User Instance=True

i zwyczajnie używać tej bazy danych. Warto dodać, że ten plik nie będzie na stałe powiązany z serwerem - otworzenie połączenia powoduje tymczasowe zarejestrowanie obiektu. Ale np. po zamknięciu aplikacji plik może być przesuwany itp.

Jeżeli jednak do projektu w VS.NET dołączymy taki element, to pojawi się odpowiedni wpis w DataConnection nad Server Explorer - będzie można tworzyć obiekty w bazie itp. To bardzo wygodny mechanizm - zwłaszcza gdy planujemy dystrybucję naszej aplikacji wraz z początkową bazą danych.

Należy podkreślić, że na jednej maszynie może być kilkanaście instancji SQL Server - a ponieważ niektóre elementy VS.NET 2005 Beta mogą współpracować tylko z SQL Express, warto mieć instancję o nazwie SQLEXPRESS.

Nadawanie użytkownikom praw dostępu

Jeżeli trzeba zdefiniować użytkownika w SQL Express, można użyć np. polecenia:

USE [PCWKVS2005]

CREATE LOGIN [test] WITH PASSWORD=N'test',

DEFAULT_DATABASE=[PCWKVS2005], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

CREATE USER [test] FOR LOGIN [test]

WITH DEFAULT_SCHEMA=[dbo]

Najpierw tworzymy login pozwalający na zalogowanie się do SQL Server. Potem tworzymy użytkownika w danej bazie danych i przypisujemy mu dany login. Aby skasować użytkownika, używamy:

drop user [test]

drop login [test]


Zobacz również