Piszac wlasna architekture pod aplikacje internetowe natknalem sie na pewien problem, zreszta, jak to zwykle sie okazuje, nie ja jeden (podobny watek: http://forum.php.pl/index.php?showtopic=44563)

Chodzi o powiazanie warstwy modelu (w modelu MVC) wraz z podwarstwa DAO. W przypadku pojedynczych tabel problemu nie ma, a rozwiazuje to mniej wiecej tak:
W akcji (czy inaczej PageController lub ActionController) uruchamiam kontretna klase DAO i jej metoda wypelnia model danymi i zwraca (w zaleznosci od wynikow - pojedynczy obiekt modelu lub tablice obiektow), mniej wiecej:

[PHP] pobierz, plaintext 
<?php
$this->_request = $request;
$db = DBManager::polacz();
$this->_db = $db;
$this->_modeldao = new KlientDao($db);
$klient = $this->_modeldao->szukajKlienta(array('id','imie','nazwisko','id_firmy'),array('id'=>$id));
?>
[PHP] pobierz, plaintext 

W $klient mam model (obiekt) klienta o konkretnym id i jego wlasnosci (id, imie, nazwisko,id_firmy). Moge teraz to latwo przekazac do kontenera, a pozniej wieswietlic dane w widoku.

Tego typu praktyka, ze model jest wypelniany danymi pobranymi z warstwy DAO (lub np. w przypadku formularza dodawania/edycji - od usera), wydaje sie dobra.

W przytoczonym wczesniej watku user Bora opisal swoje wlasne rozwiazanie + zdanie

"Coś takiego powinno ładnie działąć, problem jest dopiero w przypadku powiązań między tabelami. "

No wlasnie, jak sobie radzicie, jezeli klient ma w bazie relacje np. z firma i ten klient kupil jakas rzecz (wiec takze relacje z zakupy - w uproszczeniu ... chociaz to w zakupach jest id klienta)

Aktualnie robie to tak - tworze nowy obiekt DAO i szukam firmy:

[PHP] pobierz, plaintext 
<?php
$this->_modeldao = new FirmaDao($this->_db);
$firma = $this->_modeldao->szukajFirmy(array(),array('id'=>$klient>id_firmy));
?>
[PHP] pobierz, plaintext 

Jest to jakies rozwiazanie w przypadku jednego klienta, ale co w przypadku listy n klientow ? Mamy wtedy n+1 zapytan SQL :/ Oczywiscie mozna stworzyc sobie inna metode w klasie DAO, np.
szukajKlientowiFirmy, gdzie zapytanie byloby oparte na zlaczeniach, ale wtedy jak wydzielic pola i jak tworzyc obiekty. A moze firma w tym wypadku powinna byc tablica asocjacyjna w modelu klienta, a nie osobnym obiektem. Jak Wy to rozwiazujecie, bo przeciez podstawa ?

Niby byla juz podobna dyskusja na tego typu temat http://forum.php.pl/index.php?showtopic=64564&st=0, ale niezbyt byla rowinieta, poza tym, ze mozna skorzystac z Propela....

@Reigon takie powiązanie stanowi osobny model, to chyba powinno rozjaśnić, a jak nie można operować na warstwie bazy to tworzy się coś między co obsługuje.
Np. przy zakupach możesz pobrać wszystkie transakcje, ale też można danego klienta. Można pobrać pojedynczą, aby w danych zwrotnych były jakieś informacje o produktach które były kupione...
Więc przydatny byłby model, który obsługuje transakcje na takim poziomie. A w kontrolerach tworzysz instancje takiego obiektu i korzystasz z jego metod, a w samym modelu decydujesz jak i skąd pobrać dane.
Trzeba tylko pamiętać o tym, aby dany model obsługiwał tylko pewną konkretną rzecz (taki model jest obiektem więc powinien za dużo mieć na głowie )

Dzieki czyli jak chce wyswietlic liste klientow wraz z nazwa firmy, to przydalby sie model, ktory posiada wlasciwosci idKlienta, imie, nazwisko, nazwaFirmy...i tablice takich obiektow przekazuje do widoku...no w sumie niezle rozwiazanie,

Inne jakie wymyslilem, to w przypadku wystapienia zlaczenia kilku tabel wysylanie dosyc malo obciazajacego zapytania 'desc nazwa_tabeli' (tyle razy ile zlaczonych tabel), ktora zwroci liczbe pol w tabeli (w przypadku podania pol wprost obyloby sie bez tego zapytania)...wtedy po po przetworzeniu n-kolumn w wierszu tworzymy obiekt Klient, a pozniej dla kolejnych kolumn obiekt Firma. Oczywiscie zadzialaloby to, gdyby pola z poszczegolnych tabel wystepowaly jedne po drugich (tak jest domyslnie, bez przestawien)

Zastanawiam sie teraz, ktore rozwiazanie byloby lepsze
Jednak w sumie w przypadku wyswietlania typowych list userow nie ma koniecznosci i potrzeby tworzenia dwoch obiektow (Klient i Firma), bo i tak zadne operacje poza wyswietleniem nie beda na nich przeprowadzane. Dlatego porobie osobne modele dla takich przypadkow

jeszcze inne (pewnie najlepsze) to zastosowanie Propela - ale ze aplikacja jest juz dosyc zaawansowana, a prace magisterska trzeba konczyc, to moze innym razem