Siema.
Napisałem klasę która zarządza pulą połączeń do DB. Martwi się o to, ile jest otwartych połączeń, czy obiekt wołający o połączenie je dostanie i oznacza aktualnie używane połączenia. W przyszłości planuję zaimplementować jeszcze parę fajnych funkcji. Dla klasy używającej taki connection pooling jest to przezroczyste - prosi o połączenie i jak dostanie je to coś tam robi, albo nie dostaje i od niej zależy czy czeka, czy nie.
Wiadomo, connecion pooling jest jeden - jedna kolekcja składująca otwarte połączenia i zarządzająca nimi. Obiektów bazodanowych jest o wiele więcej. W zasadzie może być ich nieskończona ilość, i mogą być generowane dynamiczne. Nie chce tworzyć CP jako obiektu poza klasą obiektu bazodanowego, bo musiałbym się martwić o jego zwalnianie i tworzenie, albo musiałbym w środku obiektu szukać CP, lub co gorsza przekazywać go do CP jako paramter metod, co sprawi, że użytkownik takiej klasy obiektu bazodanowego popełni parę razy błędy, i parę razy zapomni dodać CP lub przekaże niewłaściwy.
Pomyślałem, żeby zamiast cudować po prostu umieścić statyczne pole typu TFBConnectionCollection (connecion pooling) w klasie obiektu bazodanowego. Byłoby to pole prywatne, żeby było to przezroczyte dla użytkownika klasy obiektu bazodanowego. User nie wie, jak obiekt łączy się do bazy, jakim połączeniem i czy aktualnie są wolne połączenia, jest to sprawa zarządzana automatycznie a obiekt wykonuje jedynie operacje docelowe bez zbędnej otoczki dostępu do danych.
W zasadzie chce żeby to było statyczne, bo nie chce wielu klas zarządzających połączeniem - nie taka idea, a nie chce zeby był dostęp do CP z poza wewnętrznych mechanizmów obiektów bazodanowych.
Mam teraz pytanie - czy taka hierarchia jest właściwa ?? Czy w dobry sposób chce używać connection pooling, oraz czy dobrym pomysłem jest osadzanie tego jako pola statycznego ??
Z innej beczki męczył mnie post @_13th_Dragon, poczytałmem i mam pytanie, czy w jakikolwiek sposób moja klasa connection pooling spełnia zasady singletona