Witam

Tak sie po prostu zastanawiam jak pisac zlozone DAO z relacja miedzy roznymi tabelami. Wedlug ogolnie przyjetych patternow (www..phppatterns.com) kazdy obiekt powinien zawierac metody jak najprostsze. Np obiekt News powinien wybierac newsy. Ale co jezeli chce aby dodatkowo wybieral dane dotyczace autora polaczone relacyjnie? Jak rozwiazac ten problem?

Hey

Ja to rozwiazalem nastepujaco :

W mojej klasie oslugujacej tabele dodalem metode laczaca dwa obiekty tabel.
Wyglada to mniej wiecej tak.
[php:1:3e1a159c9f]<?php
$dbObject =& engine::loadExtinsion('dbObject');

$this->comment =& $dbObject->factory('comments');

// user table
$cols = array (
config::get('auth', 'id_col') => 'id' ,
config::get('auth', 'user_col') => 'user'
);

$this->user = $dbObject->factory(config::get('auth','table' ));

$this->user->clearSelectedColumns();

$this->user->addSelectColumn( $cols );

$this->comment->addObjectJoin('autor_id', 'id', $this->user, 'u') ;

$this->comment->addColumnAlias( array( 'u_user' => 'autor' ), 'u' );
?>[/php:1:3e1a159c9f]

1) Laduje klase db object.
2) Tworze obiekt tabeli komentarzy
3) okreslam nazwy kolumn dla tabeli urzytkownikow
4) tworze obiekt tabeli urzytkownikow
5) czyszcze kolumny wybrane dla tabeli user
6) dodaje nowe kolumny wraz z ich nowymi aliasami
7) lacze dwa obiekty tabeli i dodaje prefiks dla kolumn tabeli user, od tad tabela user jest polaczona z tabela komentarzy, alias kolumny userow to "u" a prefiks kolumn tabeli userow to "u_"
8) zmiaeniam alias kolumny user w tabeli u na bardziej przyjazny

Po takiej konfuguracji moge normalnie urzywac obiektu komentarzy tak jaby mial jeszcze dwie kolumny (autor, u_id)

przyklad uzycia to
[php:1:3e1a159c9f]<?php
$this->comment->get(5); //znajduje po kluczu

$this->comment->get( array('autor' => 'rzseattle') ); //po autorze
$this->comment->count();
//itd.
?>[/php:1:3e1a159c9f]

Istotnie, ale to się nie tyczy tylko obiektów. Ja generalnie uwazam, że prostota prowadzi do sukcesu na wszelkich płaszczyznach - nie tylko informatycznych.


Ale nawet gdyby wybierał dodatkowo dane o autorze newsa z innej relacji, to to nadal jest wybieranie newsów, bo po prostu potrzebujesz danych z innej tabeli aby mieć kompletny pakiet informacji potrzebny do wyświetlenia newsa. Co innego gdybys np. potrzebował danych o autorze, aby użyć ich np. przy generowaniu jakiś statów zupełnie nie związanych z newsami - w takim wypadku byłoby błedem umieszczanie tego w module od newsów.

P.S po polsku pattern to po prostu wzorzec (projektowy) - ładniej brzmi

halfik, oczywiście, że można tak zrobić, i często właśnie tak się robi. Jednak niesie to za sobą wiele zagrożeń, których nie mamy w innych językach, pozwalających na pisanie szczelniejszych klas.
Dlaczego to ma takie duże znaczenie? Ponieważ nie raz się zdaża, że podczas rozwoju programu dochodzi do przebudowy struktury bazy, wiec im mniej klas musimy w tym momencie modyfikować tym większa pewność, że będzie to zrobione dobrze.
Niestety - taki sposób pisania wiąże się ze znaczną komplikacja struktury powiązań pomiędzy obiektami w php.
Doprowadza też do spadku wydajności... Ale jednak się sprawdza, czego przykłądme są np. tutos, albo eZ.
A wraz z pojawieniem się php5 na rynku, taki sposób pisania ma coraz większe szanse na sprawdzenie.

Tutaj smiem się nie zgodzić. Jeśli wpierw dobrze zaplanujesz cały projekt, a w tym bazę to nie ma prawa już w czasie pisania kodu dochodzić do zmian struktury. A raczej, istnieje małe prawdopodobienstwo, że zmiany struktru bazy będą czeste - jak już to sporadyczne - i dlatego właśnie warto wiele czasu poświęcić na projektowanie przed przystąpienim do pisania. P.S Anglicy dla przykładu z tego co mi wiadomo 70% czasu poświęcają na projekt a pozostałe 30% na programowania. Myślę, że w tym miejscu warto się zastanowić


Dokładnie tak jak piszesz. Ale nadal będę się upierał: dlaczego nie spróbować zminimalizować "pkt. zaskoczeń" poprzez zwiększenie ilości czasu poświęconej samemu projektowaniu ?


hmm... ale jakbyś zrobił to samo strukturalnie też musisz odpowiednio wszystko powiązać, aby całość była sprawna i czytelna. A co do wydajności - taka jest cena za uproszczenie (bo tym jest całe OOP) progamowania. A pisząc o uproszczeniu: chodzi mi tutaj o fakt, że łatwiej jest przełożyć problem z rzeczywistości na język programowania, gdy mamy do dyspozycji OOP, niż gdybyśmy robili to strukturalnie.


Czy będzie miał szanse? Ja bym zgadywał, że stanie się dużo bardziej popularny od strukturalnego i mało kto będzie się tutaj przejmował spadkiem szybkości działania oprogramowania mając przed oczami zalety OOP Powiedzmy sobie szczerze: czy JAVA (najpopularniejszy teraz chyba język OOP) była by tak poteżna i popularna, gdyby była językiem strukturalnym? A teraz php, który jest de facto strukturalny - świetne narzędzie - zauważmy jaką siłą i popularnością dysponuje - i czy teaz gdy będzie w pełni obiektowy (choć nie bedzie to samo OOP, a hybryda), czy nie zyska jeszcze więcej zwolenników? Ciekawie, ciekawie zapowiada się przyszłość PHPa po wejściu 5 hehe

Co prawda nie wiem, jak długo masz już styczność z programowaniem bardziej zaawansowanych systemów. Ja jednak, mimo że moje doświadcznienie nie jest jeszcze duże, a to co wiem o projektowaniu baz danych to własciwie wciąż przedszkole (np. największy mój system posiada około 20 mocno powiązanych ze sobą tabel - a na codzień spotykamy się w wielu przedsiębiorstwach z programi, które wykorzystują ich setki, więc i ich projektowanie wyglada całkiem inaczej) ale już przekonałem się, że praktycznie nigdy nie można do końca przewidzieć oczekiwań klienta.
Oczywiście dużo zależy tu od sstylu naszej pracy, oraz wykorzystanej metodyki projektowania, ale np. w przypadku projekotwania i pisania w oparciu o XP, to właściwie cały proces programowania polega na wprowadzaniu do systemu kolejnych zmian.


W to, że prograwanie OOP jest w tej chwili jednyną rozsądną alternatywą w przypadku programowania, nie wątpię. Nie wyobrażam sobie już pisania w inny sposób (dlatego troszkę np. boli mnie używanie strukturalnych języków np. w bazach danych)
Mówiłem natomiast tylko o takim podejściu do pisania klas, w którym 1 przykładowa tabela to 1 obiekt do jej obsługi, i nigdzie nie robi się od tego wyjątków. Przyznam szczerze, że teraz, mimo ze widziałem tego typu rozwiązania, nie wyobrażam sobie trzymania sie tej zasady w 100% .
Ale kto wie do czego dojdzie z czasem?