Sterownik bazy kontra własny handler sesji Opcje

[Jarod]

Piszę frameworka. Napisałem klasę do obsługi bazy danych i własny handler sesji (sesje trzymane w bazie).
Przed chwilką jeszcze analizowałem pewne rzeczy i natrafiłem na pewien dylemat. Już wyjaśniam o co chodzi.
Cały framework opiera się na pliku konfigurcyjnym (normalne). W konfigu mam dwie sekcje [Database] i [Sessions]. W sekcji database ustawiam parametry połączenia z bazą podobnie jak w sekcji Session. Dlaczego? Bo chcę mieć możliwość przechowywania sesji w innej bazie niż docelowa.. Taki bajer:)

Sesję tworzę w ten sposób:

[PHP] pobierz, plaintext 
<?php
$oSession = new CubeSession();
?>
[PHP] pobierz, plaintext 

Konstruktor sprawdza czy są ustawione wymagane dane do połączenia z bazą i wywołuje metodę connect(), która otwiera połączenie z bazą danych.

Natomiast z bazą łącze się w następujący sposób:

[PHP] pobierz, plaintext 
<?php
$oDatabase = new Mysql();
?>
[PHP] pobierz, plaintext 

Konstruktor sprawdza czy wszystkie wymagane parametry są ustawione i wywołuje metodę connect(), która nawiązuje połączenie z bazą.

Sedno sprawy:
W aplikacji uruchamiam sesję i tworzę instancję klasy Mysql, żeby pobierać jakieś dane z bazy. Problemem jest to, że mam dwa otwrte połączenia przypadające na jeden skrypt... :/



Zacząłem się zastanawiać czy nie lepiej tworzyć z jednego ogólnego połączenia. Czyli najpierw tworzę instancję klasy Mysql i przekazuję obiekt do instancji klasy sesji. Np.

[PHP] pobierz, plaintext 
<?php
$oDatabase = new Mysql();
$oSession = new CubeSession($oDatabase);
?>
[PHP] pobierz, plaintext 

i obiekt $oSession korzysta z poączenia przekazanego w obiekcie $oDatabase..


Nie wiem czy dobrze rozumuję, czy to jest zgodne z OOP?

Nawet jeśli tak to pojawia się inny problem. Muszę sprawdzać czy parametry do połączenia z bazą (w sekcji Database) są identyczne jak parametry do połączenia z bazą dla sesji (w sekcji Session). Jeśli nie to każdy obiekt korzysta ze swojego połączenia..

Nie wiem czy jest sens tak się z tym pieprzyć czy nie lepiej po prostu korzystać w jednym skrypcie z dwóch (nawet takich samych) połączeń z bazą..

Co o tym sądzicie?

[LBO]

Ja bym skorzystał z rejestru. Wrzucił tam $oDatabase i domyślnie, żeby klasy frameworka korzystały z tej instancji (połączenia). Natomiast nowe połączenie, żeby było opcjonalne (w twojej implementacji mogłoby to wyglądać w ten sposób, że jeżeli przekażesz obiekt MySQL do konstruktora, CubeSession, to ten moduł/komponent będzie z niego korzystał, jeżeli nie, wyciąga "globalny" z rejestru).

Ten post edytował LBO 6.02.2007, 22:13:58

[athabus]

Można też zrobić to tak jak np. w Zend Framework, tj. jeśli Twój framework zakłada istnienie jednego głównego pliku, który zawsze rozpoczyna działanie aplikacji (czyli np. index.php) to w tym pliku możesz dokonać wstępnych ustawień. Np. ustawić domyślne połączenie z bazą danych.
czyli

[PHP] pobierz, plaintext 
<?php
$oDatabase = new Mysql();
CubeSession::setDefaultConnection($oDatabase);
?>
[PHP] pobierz, plaintext 

Wtedy obiekt typu CubeSession będzie zawsze korzystał z domyślnego połączenia tak długo jak nie ustawisz innego. Dzięki temu będziesz miał dwa otwarte połączenia tylko i wyłącznie wtedy, gdy będziesz tego naprawdę potrzebował.

Swoją drogą pytanie, czy CubeSession ma korzystać z połączenia czy z całego adaptera. Moim zdaniem jeśli to framework, to CubeSession powinien korzystać z całego adaptera, tak aby w razie zmiany bazy danych można było zmienić tylko adapter bez konieczności ingerencji w CubeSession.

[Jarod]

Można też zrobić to tak jak np. w Zend Framework, tj. jeśli Twój framework zakłada istnienie jednego głównego pliku, który zawsze rozpoczyna działanie aplikacji (czyli np. index.php) to w tym pliku możesz dokonać wstępnych ustawień. Np. ustawić domyślne połączenie z bazą danych.
czyli

[PHP] pobierz, plaintext 
<?php
$oDatabase = new Mysql();
CubeSession::setDefaultConnection($oDatabase);
?>
[PHP] pobierz, plaintext 

Wtedy obiekt typu CubeSession będzie zawsze korzystał z domyślnego połączenia tak długo jak nie ustawisz innego. Dzięki temu będziesz miał dwa otwarte połączenia tylko i wyłącznie wtedy, gdy będziesz tego naprawdę potrzebował.

Niby tak ale nie chcę się za bardzo ograniczać. Poza tym mogą wystąpić 3 różne sytuacje:
- sam proces autoryzacji - najpierw otwieramy połączenie z bazą aby sprawdzić czy dane są poprawne, jeśli tak to startujemy sesje i użytkownik jest zalogowany..
- zawsze na starcie startujemy sesje (zliczamy też anonimowych użytkowników)
- startujemy sesje w głównym pliku ale w nim nie potrzebujemy wydobywać zapytań z bazy

Swoją drogą pytanie, czy CubeSession ma korzystać z połączenia czy z całego adaptera. Moim zdaniem jeśli to framework, to CubeSession powinien korzystać z całego adaptera, tak aby w razie zmiany bazy danych można było zmienić tylko adapter bez konieczności ingerencji w CubeSession.

Z adaptera (jeśli myślimy o tym samym). Rodzaj wykorzystywanej bazy jest ustawiany w pliku konfiguracyjnym. Wystarczy zamienić 'Mysql' na 'Postgresql' i cube korzysta z drugiego (jak napisze bo narazie mam napisany tylko do mysqla).