[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]

Zauważ, że przykładową klasą Użytkownik mieszasz już nieco strukturę. Są w niej bowiem funkcje z różnych "warstw". I tak:
Walidacja -> Model
Rejestracja -> Model
Logowanie -> Kontroler
Wylogowanie -> Kontroler
Nowe hasło -> Model
Zmień hasło -> Model
Zmień dane -> Model
Pokaż rabat -> Widok
Problem w tym, że nawet to jest w sposób, który nie do końca jest prawidłowy. Dlaczego?Bo część z tych operacji jest wykonywana poprzez więcej niż 1 "warstwę". Przykładowo Pokaż rabat jest tak naprawdę Widokiem, ale musi posłużyć się metodami Modelu by uzyskać te dane. Tak naprawdę więc nie ma w klasie usera żadnego widoku. Jest za to jeden wielki model danych użytkownika, którego metodami posługują się inne klasy. Nie ma czegoś takiego jak logowanie czy wylogowanie, bo to kontroler zupełnie innej klasy. Tak naprawdę w klasie użytkownik masz metody służące do jego dodania, usunięcia, wyciągnięcia pewnych lub wszystkich danych bądź ich zmiany. Rabat jest tutaj czymś zupełnie obcym i można powiedzieć, że jest osobną klasą. Walidacja nie jest osobną metodą, gdyż musi być implementowana w każdej z metod odpowiedzialnych za edycję. Nie napiszesz nigdy zunifikowanej wersji musiałbyś dla każdego typu pola pisać osobną metodę walidacji go. Inaczej bowiem waliduje się adres e-mail a inaczej adres www lub konkretne pole liczbowe czy znakowe. Poza tym czasem jakieś pola przy edycji w określonych przypadkach walidujesz, a inne nie, gdyż nie są nawet wypełniane. Jak wyobrażasz sobie choćby metodę walidacji z jedną metodą gdy raz posyłamy ją tylko do zmiany hasła, a innym razem do dodawania usera?
Najprościej rzecz ujmując istnieją jakby dwie klasy użytkownik. Jedna to kontroler, druga to model. User_Kontroler może wywołać metodę rejestracja, która zainicjuje User_Model łącząc ją ze źródłem danych, zwaliduje dane i gdy zwróci błąd (banalne hasło, login już istnieje, nieprawidłowe dane w formularzu lub nieprawidłowy ich format) poinformuje User_Kontroler o tym. Jeśli zaś wszystko ok to doda do źródła danych i zrobi ewentualnie coś jeszcze.

Sklep internetowy podziel na role wpierw i pomyśl co Ci potrzebne. Na pewno użytkownik, na pewno produkt i koszyk To minimum, ale w zależności od stopnia komplikacji rozszerzy się to zapewne o inne. Nie ma jasnej i gotowej odpowiedzi o podział, gdyż niemal każdy inaczej widzi go, choć teoretycznie każdy korzysta z tej samej definicji (IMG:style_emoticons/default/winksmiley.jpg)