[PHP]podział na klasy Opcje

[perhydrol]

Witam,

od jakiegoś czasu eksperymentuję z obiektowym PHP, jednak moje strukturalne myślenie skutecznie mi to utrudnia.
Tylko proszę nie odsyłajcie do przeszukiwania tematów jak wielokrotnie twierdzicie iż temat był poruszany tysiące razy,
ja jednak szukając odpowiedzi w postach już istniejących na tym forum nie znalazłem satysfakcjonującej odpowiedzi.

Mam prośbę, czy mógł by ktoś mi wypisać na przykładzie sklepu internetowego podział na klasy, oraz zakwalifikować je do odpowiednich części:
Model, View, Controller

Coś w stylu listingu klas, i nie jest to z mojej strony wyręczanie się Wami, a jedynie chciał bym dostrzec jak szczegółowo należy podejść do podziału danej dziedziny sklepu internetowego na klasy. Dzięki przypisaniu ich do odpowiednich części MVC, myślę że będę mógł szybciej i lepiej zrozumieć to z czym się borykam. Dodam może że do UML-a używam "NetBeans IDE 6.7.1"

a interesujące mnie rozwiązanie to coś w stylu:

[PHP] pobierz, plaintext 
class DB_Connect           // klasa inicjująca połączenie z baza danych
class DB_View               //  klasa zapytań do bazy danych 
....                               //   tu kolejne pytanie czy jest sens przechowywać wszystkie zapytania do bazy danych, np SELECT ... w jednym pliku?
....                              //    no i jeszcze jak by mógł mi ktoś zaznaczyć która klasa do jakiej części modelu MVC się zalicza
[PHP] pobierz, plaintext 

Ten post edytował nospor 14.10.2009, 23:08:53

[thek]

MVC robią dokładnie to co sugeruje nazwa. Różnica polega na tym, że pewne klasy nie będą miały wszystkich trzech. Przykład? Klasa połączenia z bazą danych. Zauważ, że ona nie musi mieć widoku, gdyż nigdzie nie prezentujesz danych tylko przepychasz je do innych klas. Myśl własnie w ten sposób. Jeśli chcesz jakieś dane uwidaczniać, to projektuj do tego widok. Chcesz wyciągać dane? Pomyśl o modelu. Gdy trzeba nad tym wszystkim odpowiednio popracować to nie obejdzie się bez kontrolera.. Jak więc widzisz kontroler jest w zasadzie zawsze, bo musi kierować poczynaniami i przepływem danych. Czasem niepotrzebny jest klasie model, jeśli nie operujesz na danych pobieranych z zewnątrz (baza czy pliki).
Ja osobiście robię tak, że mam zawsze główny kontroler dziedziczący po jakimś template i do niego wrzucam widoki. Jeśli któryś z widoków pobiera dane to ma on dostęp albo do dedykowanego mu modelu, albo korzysta z pewnego globalnego modelu. Jeśli zaś ten widok ma podwidoki, to mają one zazwyczaj własne kontrolery i własne widoki. Całość układa się wtedy w swego rodzaju drzewko zależności. W takiej sytuacji do widoku głównego przez główny kontroler są wysyłane mniejsze widoki korzystające z własnych kontrolerów, widoków i modeli (choć mogą korzystać z pewnego głównego modelu dla danych lub nie korzystać z modeli wcale). By je odróżnić nadaję im odpowiednie nazewnictwo. Ciekawostką dla początkujących jest choćby klasa autoryzacji. Zauważ, że nigdzie ona nie prezentuje danych, czyli jest klasą bez widoku. Ma model by pobrać dane ze źródła, Kontroler dla przepływu i obróbki danych i nic więcej nie trzeba do szczęścia.