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

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.