[ASP.NET] Polaczenie z SQL w konstruktorze klasy

	B O A R D
	» Board » Zadaj pytanie » Archiwum » Szukaj » Stylizacja

M E N U

» Nowości

» Archiwum

» Recenzje / Testy

» Board

» Rejestracja

Szukaj @ TwojePC

	OBECNI NA TPC
	» DYD 07:33 » Ramen 07:31 » leosh 07:31 » Blum 07:29 » Kelso1 07:29 » m&m 07:28 » Glock19 07:26 » steve 07:20 » rad 07:17 » dugi 07:15 » mark_d 07:10 » Adolph 07:04 » @GUTEK@ 07:03 » AfiP 06:58 » infinity 06:57 » buddookan 06:57 » ili@s 06:56 » ekspert_I 06:51 » Kenny 06:50 » Markizy 06:48 Dzisiaj przeczytano 13296 postów, wczoraj 40350 Szybkie ładowanie jest: wyłączone.

ccc

A R C H I W A L N A W I A D O M O Ś Ć

[ASP.NET] Polaczenie z SQL w konstruktorze klasy , Maners 1/06/06 16:50
Witam

Mam takie ktorkie pytanie: czy to dobry pomysl umieszczac kod do laczenia z SQLem w konstruktorze klasy a rozlacznie w destruktorze? Chodzi mi o to czy sama idea takiego rozwiazania niesie ze soba jakies ryzyko?

hmm , bartek_mi 1/06/06 17:35
z baza sie laczysz jak cos wysylasz i odbierasz
otwarte polaczenie jest nieeleganckie
dzisiaj jest jutrzejszym wczoraj
1. hmm , bartek_mi 1/06/06 18:05
  uscisle jak to sie robi w ado (niewazne czy winapp czy asp)
  
  w konstruktorze masz connection
  
  jak w metodzie chcesz czytac/pisac to polaczenenie otwierasz, robisz co tam chcesz w bazie, polaczenie zamykasz
  dzisiaj jest jutrzejszym wczoraj
Ciekawy problem... , pachura 1/06/06 17:54
Oczywiście z SQL-em nie można "się połączyć", można wydać napisane w nim zapytanie ;)

Twoje podejście ogólnie jest dobre i nazywa się RIAA (Resource Initialization Is Acquisition) - dzięki temu np. w C++ możesz napisać:

{
File plik('test.txt');
// ...różne operacje na zmiennej plik...
}

I nie musisz się martwić czy plik zostanie zamknięty, nie musisz się martwić wyjątkami - załatwia to za Ciebie destruktor po wyjściu ze scope'a (po przekroczeniu klamr), natomiast w Javie musisz wszędzie pisać try...finally, co np. dla mnie jest upierdliwe.

Aczkolwiek powstaje tu pytanie czy w konstruktorze chcesz sobie tylko utworzyć jakieś obiekty zapytań (Statement/Query - jak to się tam nazywa), czy też faktycznie łączyć się z bazą, wysyłać do niej login/hasło etc.? W drugim przypadku byłoby to słabe rozwiązanie - zwykle aplikacja wymaga tylko jednego-dwóch połączeń z bazą na których wykonuje różne zapytania - ciągłe nawiązywanie i zamykanie połączenia z bazą byłoby bardzo kosztowne. Wówczas powinieneś takie połączenie pobierać z singletona - będzie otwierane przy pierwszym próbie komunikacji z bazą i pozostanie otwarte do końca pracy programu.
1. U wyglada to tak , Maners 1/06/06 19:56
  Mam klase przeznaczona do wyswietlania roznego typu tresci z bazy danych. Dziala ona jako mikro API ktore docelowo bedzie uzywane na roznych stronach i dzieki temu bede mogl "ukryc" przed nimi w jaki sposob dane sa pobierane z bazy danych. Sam konstruktor nie wykonuje zadnych zapytan do SQLa, jedynie ustanawia polaczenie i automatycznie zamyka je kiedy obiekt jest zniszczony. Dopiero poszczegolne methody tej klasy wykonuja odpowiednie zapytania uzywajac polaczenia ustanowionego w konstruktorze. Jako ze to ma byc uniwerslne API, to nie jestem w stanie przewidziec ile i ktore metody beda wywolane przez kod danej strony. W ksiazkach dotyczacych programowania w .NET zawsze ustanawiaja i zamykaja polaczenie wewnatrz wykonywanej metody, co w moim przypadku wydaje mi sie nie zbyt efektywne, bo jesli wywolywanych jest powiedzmy 10 metod, jedna po drugiej, to polaczenie jest 10 razy otwierane i 10 razy zamykne podczas "zycia" 1 obiektu. Umiesczenie laczenia i zamykanie w konstrukotrze i destruktorze klasy wydaje mi sie najoptymalniejszym rozwizaniem i zapewne tak jest, jesli mowa o jezykach nie zarzadznych jak C++, ale w przypadku .NET mamy Garbage Collector, ktory sam decyduje kiedy znisczyc dany obiekt i stad sa moje watpliwosci n/t slusznasci tego rozwiazania.
  1. Garbage Collector nie ma nic do gadania , bwana 2/06/06 08:59
    przecież Twoim problemem jest uniknięcie otwierania/zamykania połączenia z bazą, a nie zwalnianie pamięci po zmiennej Connection.
    
    Twoje rozwiązanie wygląda dobrze, przynajmniej w kwestii wydajności. Być może obawiasz się, że GC zniszczy obiekt Connection "zbyt wcześnie" jeśli tworzysz go w konstruktorze - o ile wiem, nic takiego nie nie może nastąpić - dopóki nie zamkniesz jawnie połączenia z bazą, bądź nie wykona się (jawnie lub niejawnie) destruktor Twojej klasy API, na pewno obiekt Connection nie zostanie określony jako do wyzamiatania.
    "you don't need your smile when I cut
    your throat"
  2. Da się chyba uzyskać deterministyczne wywołanie destruktora... , pachura 2/06/06 10:29
    Nie pisałem w C#, ale zdaje się była taka konstrukacja jak:
    
    using (obiekt) {
    // różne operacje
    // ...
    } // po wyjściu z klauzuli using na pewno będzie wywołany destruktor dla "obiekt"
    
    Było też coś takiego jak interfejs IDisposable - bodajże również służył do tego.
Dzieki , Maners 2/06/06 16:51
wszystkim za odpowiedzi.