PDO i współpraca z własnymi klasami Opcje

[Jawor]

Witam

Mam pytanie odnośnie współpracy PDO z własnymi klasami.

Ktory sposob powinno sie uzywac:

1. Polaczenie z baza poza klasa (wlasna) i przekazywanie do niej obiektu typu PDO. Wszystkie zapytania, operacje na danych z bazy odbywaja sie we wlasnej klasie.

2. Wszystkie operacje zwiazane z baza odbywaja sie poza wlasna klasa (zapytania, pobieranie danych), a do mojej klasy przekazuje juz np. pobrane z bazy dane.


Do tej pory caly czas pisalem strukturalnie, ale postanowilem to zmienic i oto pierwszy dylemat jaki napotkalem na swojej drodze (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował Jawor 9.11.2008, 16:27:35

[markac]

Sorry orglee, ale ja już wolę __autoload. W systemie nie powinny wystąpić klasy o tych samych nazwach i dlatego ryzyko kolidowania klas spada do minimum. Przykład:

Andrew: 03-Nov-2006 12:26

[PHP] pobierz, plaintext 
<?php
    function __autoload($class_name)
    {
        //class directories
        $directorys = array(
            'classes/',
            'classes/otherclasses/',
            'classes2/',
            'module1/classes/'
        );
       
        //for each directory
        foreach($directorys as $directory)
        {
            //see if the file exsists
            if(file_exists($directory.$class_name . '.php'))
            {
                require_once($directory.$class_name . '.php');
                //only require the class once, so quit after to save effort (if you got more, then name them something else
                return;
            }           
        }
    }
?>
[PHP] pobierz, plaintext 

Mamy w ten sposób także uzupełnianie kodu w Eclipse, oczywiście jeśli zastosujemy odpowiednie tagi dokumentujące same klasy. Co do Registry, chyba Ty to napisałeś, że istnieje możliwość nadpisania? Mylisz się. W takich przypadkach nie stosuje się get() i set(), a odpowiednio nazwane metody, np. getPDO(), getSession(). Mamy w ten sposób załatwione także uzupełnianie kodu i wykluczenie możliwości nadpisania kodu. Samo zastosowanie get i set jest to po prostu lenistwem, niedoświadczeniem i posiadaniem złych nawyków, o dziwo, dotyczy tylko programistów PHP?

Ten post edytował markac 3.12.2008, 09:27:06

[starach]

Sorry orglee, ale ja już wolę __autoload. W systemie nie powinny wystąpić klasy o tych samych nazwach i dlatego ryzyko kolidowania klas spada do minimum.

Nie ma możliwości że wystąpią.

[PHP] pobierz, plaintext 
<?php
$ob = Instance::Get('library.template.cache.data.package.collection');
?>
[PHP] pobierz, plaintext 

Kod załaduje plik w katalogu "[projekt_root]/library/Template/Cache/Data/Package/Collection.php" ( wielkość liter nieprzypadkowa ) i utworzy obiekt klasy Template_Cache_Data_Package_Collection lub zwróci go z rejestru jeśli był już utworzony wcześniej.
W zmiennych klasowych stosuję nazewnictwo rozróżniające czy dana zmienne jest obiektem czy prymitywem ( $this->counter - obiekt $this->_counter = integer / float / double / etc. ). Mimo to nie wyobrażam sobie żeby nie napisać PHPDoc'owego @var celem lepszej czytelności i przejrzystości.

Co do Registry, chyba Ty to napisałeś, że istnieje możliwość nadpisania? Mylisz się. W takich przypadkach nie stosuje się get() i set(), a odpowiednio nazwane metody, np. getPDO(), getSession(). Mamy w ten sposób załatwione także uzupełnianie kodu i wykluczenie możliwości nadpisania kodu. Samo zastosowanie get i set jest to po prostu lenistwem, niedoświadczeniem i posiadaniem złych nawyków, o dziwo, dotyczy tylko programistów PHP?

Stosowanie setterów i getterów dla poszczególnych obiektów moim zdaniem nie jest wygodnym rozwiązaniem bo kompletnie burzy intuicyjność frameworka. Jest to coś czego nienawidzę na przykład w Joomli. Różnica między zaproponowanym przez ciebie rozwiązaniem i Jomlowym jest taka, że Joomla ma statyczne gettery w swoim rejestrze. Nazywam to singleton overflow. (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Ten post edytował orglee 3.12.2008, 16:56:43

[Black-Berry]

Stosowanie setterów i getterów dla poszczególnych obiektów moim zdaniem nie jest wygodnym rozwiązaniem bo kompletnie burzy intuicyjność frameworka. Jest to coś czego nienawidzę na przykład w Joomli. Różnica między zaproponowanym przez ciebie rozwiązaniem i Jomlowym jest taka, że Joomla ma statyczne gettery w swoim rejestrze. Nazywam to singleton overflow. (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Sory trochę zgubiłem się w temacie ale czy stosowanie getterów i setterów jest takie niezbędne do rozwiązania kontekstowego? Przecież wszystko można oprzeć o jakieś dziedziczenie. Gdzieś już tutaj pisałem o tym razem z przykładowym kodem. Każdy obiekt dziedziczący po obiekcie klasy Core_Context automatycznie może ustawiać sobie obiekty wymagane. Jeśli już chcemy wszystko zautomatyzować to poprostu każdy obiekt w naszym frameworku traktujemy jako Core_Object i po krzyku. Takie coś:

[PHP] pobierz, plaintext 
<?php
$ob = Instance::Get('library.template.cache.data.package.collection');
?>
[PHP] pobierz, plaintext 

Może i jest pomysłowe ale czy istnieje w jakimkolwiek poważnym oprogramowaniu? Wiem, że PHP można różnie traktować ale wydaje mi się że uniwersalne rozwiązania są najlepsze. Nawet jeśli nikt nie ma pracować w przyszłosci na Twoim kodzie tylko ty sam to trzeba dążyć do czegoś co akceptuje większość społeczności programistycznej nie tylko ta z PHP. (Sam mam jeszcze masę nietrafionych rozwiązań w swoim frameworku ale systematycznie je poprawiam. Nie piszę tutaj żeby komuś coś wytykać)

Pozdrawiam.