Twoje PC  
Zarejestruj się na Twoje PC
TwojePC.pl | PC | Komputery, nowe technologie, recenzje, testy
B O A R D
   » Board
 » Zadaj pytanie
 » Archiwum
 » Szukaj
 » Stylizacja

 
M E N U
  0
 » Nowości
0
 » Archiwum
0
 » Recenzje / Testy
0
 » Board
0
 » Rejestracja
0
0
 
Szukaj @ TwojePC
 

w Newsach i na Boardzie
 
OBECNI NA TPC
 
 » Lubek 19:02
 » Demo 19:02
 » josh 19:01
 » Mademan 19:01
 » komisarz 19:01
 » PeKa 19:00
 » Thadeus 18:59
 » MacLeod 18:57
 » hokr 18:56
 » Nebuchadn 18:54
 » DYD 18:52
 » Kool@ 18:51
 » BoloX 18:51
 » Maniak 18:50
 » Holyboy 18:49
 » Mario2k 18:46
 » DrLamok 18:44
 » Seba 18:44
 » Wedelek 18:43
 » abes99 18:42

 Dzisiaj przeczytano
 16402 postów,
 wczoraj 20635

 Szybkie ładowanie
 jest:
wyłączone.

 
TwojePC.pl © 2001 - 2019
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?

  1. 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

  2. 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.

  3. Dzieki , Maners 2/06/06 16:51
    wszystkim za odpowiedzi.

    
All rights reserved ® Copyright and Design 2001-2019, TwojePC.PL