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

To może jmail wyjaśnię dlaczego podałem taki a nie inny podział dla jasności. Jadę na Kohana 2.X co implikuje pewne podejście do programu. Tam jest, jak zapewne wiesz, podział na zasadzie klasy modeli, kontrolerów i widoków osobno. Dla zachowania przenośności i skalowalności klasy mam niejako 3 wersje w dużej ilości wypadków: Nazwa_klasy_Controller, Nazwa_klasy_Model, Nazwa_klasy_View, gdyż traktuję ją nieraz jako osobny "panel", który mogę w łatwy sposób wyrzucić, zmienić.
I tak wiele z tego co zostało wymienione jest tak naprawdę tylko wywołaniem w kontrolerze odpowiednich metod Modelu. Zauważ, że w takim wypadku niemal wszystko sprowadziłeś do poziomu kontrolera. A powiedz mi czy Kontroler tak naprawdę wie czy w bazie danych można zarejestrować kogoś? Nie wie. Musisz w kontrolerze zapytać model czy taki user już istnieje i dopiero on Ci odpowie zgodą lub nie na operację. W kontrolerze więc wywołuję metodę user_model->nowy_user($_POST) i oczekuję na efekty. To na poziomie modelu przebiegnie walidacja danych, a ja jedynie zwrot dostanę czy operacja przebiegła prawidłowo czy nie( w pewnej formie przeze mnie wybranej) i ewentualnie od niej podejmę jakieś działanie. Ujmując to inaczej... Napisałem gdzie tak naprawdę dzieje się podstawowa część danej opcji. Bo czy napisanie w kontrolerze funkcji do zmiany hasła w stylu
public function zmien_haslo($user, $nowe) {
(...)
}
jest inne od tego samego w modelu? To model ma się zająć operacjami na danych a nie kontroler. Ja co najwyżej mogę z kontrolera modelowi to zlecić i zinterpretować wynik otrzymany. Myślę, że rozumiesz moje podejście. Kontroler sterować ma przepływem danych, a nie na nich operować (walidować, obrabiać). Z takim podejściem na model zrzuciłeś jedynie wykonanie zapytań do źródła danych, ale całość operacji masz w kontrolerze. Odnosisz się do niego jedynie by pobrać lub wysłać dane.
Login i logout są w kontrolerze, gdyż bezpośrednio tyczą klasy User i stanu w jakim się znajduje na portalu poprzez operacje na sesji użytkownika. Koszyk zbiera informacje o wyborze produktów na stronach. Pokaz_rabat to odwołanie do wysłanie do widoku danych z jakiegoś modelu. Realizuje to kontroler tak jak napisałeś, ale to na widoku spoczywa prezentacja danych w odpowiedniej formie. Stąd tak przyporządkowałem. Nie na zasadzie gdzie programuję daną funkcję, ale gdzie jest jej meritum, na jaki element mamy zwrócić uwagę w szczególności. Wracając do Pokaż_rabat to czy nie jest to po prostu(skrótowo, bo powinienm jeszcze sprawdzić wyjście funkcji pokaz_rabaty(parametry) ) ):

[PHP] pobierz, plaintext 
User_widok_rabaty->dane = user_model->pokaż_rabaty(parametry);
User_widok_rabaty->display();
[PHP] pobierz, plaintext 

Powiedz mi więc gdzie w tym kodzie dzieje się najważniejsza część. Bo dla mnie nie byłby to kontroler (IMG:style_emoticons/default/winksmiley.jpg) A to jaki widok mi odpowiada do prezentacji danych modelu ustalam kontrolerem. Jak dla mnie to jest właśnie MVC: Model wybiera i obrabia dane, Widok je wyświetla, a Kontroler przekazuje dane Modelu do odpowiedniego Widoku. W Twoim przypadku jest tak: Kontroler pobiera dane z Modelu i dopiero w kontrolerze je obrabia i potem każe widokowi wyświetlić. Dla mnie to już pogwałcenie zasad MVC, ale wiem, że wielu programistów tak robi, zwłaszcza przy walidacji danych, bo likwiduje to kilka problemów, choćby z przepychaniem informacji o błędach i powtórnym wypełnieniu formularza tymi samymi danymi co przed wysłaniem. Rozumiem więc, że Twoje podejście jest wywołane doświadczeniami praktycznymi. Dlatego też nie uważam tego co napisałeś za błąd i nie zamierzam się kłócić w tak naprawdę nieistotnej sprawie. Po prostu zastosowałeś podejście praktyczne do pewnych problemów wynikające z doświadczenia programistycznego. Ja mam inne doświadczenia i stąd te różnice między nami.

Po prostu patrzymy na to samo z innych perspektyw. To widać już na poziomie podziału na klasy. Ja dla przykładu nie widzę sensu klasy dostawa, za to brakuje mi klasy produktu, bo z opisu sądząc można odnieść wrażenie, że dostawa istniejącego produktu do sklepu jest czymś nowym (IMG:style_emoticons/default/smile.gif) A przecież to tylko zmiana pola dostępna_ilosc dla klasy produkt. Dostawa może być ewentualnie klasą widoczną dla admina z wyszczególnieniem, że tego dnia a tego do sklepu dotarło tyle jednostek produktu takiego i takiego lub informacje związane z obsługą dostawy do klienta jego zamówienia. Jak już podkreśliłem ja i wielu innych w tematach -> wykładni MVC jest tyle ile stosujących je osób. Dla mnie patrzysz na MVC z poziomu aplikacji jako całości strony, a ja od strony roli różnych klas w niej. Stąd co innego wkładamy do nazwanych tak samo klas. By można mówić o błędnym myśleniu któregokolwiek z nas, ale musielibyśmy mieć już z góry narzucony schemat podziału klas. Tego zaś nie mamy...

Ten post edytował thek 15.10.2009, 15:07:49