Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Sterownik bazy kontra własny handler sesji
Forum PHP.pl > Forum > PHP > Pro > Archiwum Pro
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:
  1. <?php
  2. $oSession = new CubeSession();
  3. ?>

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:
  1. <?php
  2. $oDatabase = new Mysql();
  3. ?>

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.
  1. <?php
  2. $oDatabase = new Mysql();
  3. $oSession = new CubeSession($oDatabase);
  4. ?>

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).
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
  1. <?php
  2. $oDatabase = new Mysql();
  3. CubeSession::setDefaultConnection($oDatabase);
  4. ?>


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
Cytat(athabus @ 8.02.2007, 12:30:08 ) *
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
  1. <?php
  2. $oDatabase = new Mysql();
  3. CubeSession::setDefaultConnection($oDatabase);
  4. ?>

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
Cytat(athabus @ 8.02.2007, 12:30:08 ) *
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).
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.