Sterownik bazy kontra własny handler sesji |
Sterownik bazy kontra własny handler sesji |
6.02.2007, 21:57:22
Post
#1
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) |
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:
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:
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.
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? -------------------- ”Godzina nauki w życiu nowoczesnego apostoła jest godziną modlitwy.”
(św. Josemaría Escrivá, Droga, 335) |
|
|
6.02.2007, 22:13:33
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 415 Pomógł: 117 Dołączył: 7.09.2005 Skąd: Warszawa Ostrzeżenie: (0%) |
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 |
|
|
8.02.2007, 12:30:08
Post
#3
|
|
Grupa: Zarejestrowani Postów: 898 Pomógł: 48 Dołączył: 2.11.2005 Skąd: Poznań Ostrzeżenie: (0%) |
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
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. |
|
|
8.02.2007, 19:57:42
Post
#4
|
|
Grupa: Zarejestrowani Postów: 1 190 Pomógł: 27 Dołączył: 23.04.2005 Ostrzeżenie: (0%) |
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
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). -------------------- ”Godzina nauki w życiu nowoczesnego apostoła jest godziną modlitwy.”
(św. Josemaría Escrivá, Droga, 335) |
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 21:55 |