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

Dla mnie termin baza danych jest jednoznaczny i stąd tak to odebrałem. W takich sytuacjach by unikać nieporozumień używam po prostu dane lub źródło danych. To terminy na tyle abstrakcyjne, że można pod nie podpiąć jakąkolwiek formę danych.

Co do notacji wielbłądziej jestem zwolennikiem. W PHP sens nabiera węgierska, bo nieraz w locie się zmienia typ, a to nie zawsze jest pożądane.

Odnosząc się do przykładu zgadzam się, że tak powinno to wyglądać, z tym, że tak naprawdę sparsowanie nie jest potrzebne kontrolerowi. Ono się już wewnątrz samego modelu powinno wykonać. Ty podajesz parametry a w modelu odbiera je, parsuje i przetwarza w powiązaniu ze źródłem danych. Tak zwrócone dane kontroler dystrybuuje do widoku (lub kilku). Dla mnie w takim wypadku nie ma znaczenia czy kontroler wie czy nie z czym ma do czynienia. Gdyby jakiś przykład podać, to myślę, że dobrym mógłby by być JS, a konkretnie aplikacja z AJAX i powiązanymi select. Kontroler nie wie jakie ma dostępne możliwości. Źródło danych dynamicznie je dołącza. Kontroler ma tylko dostęp do metod ogólnych, a źródło wybiera na podstawie dynamicznie dołączanej listy. W ten sposób możemy w zależności od sytuacji okrajać lub poszerzać możliwości aplikacji, zaś kontroler mimo braku świadomości warstwy niżej może nakazać modelowi stosowanie konkretnego typu danych. Po prostu wywoła metodę ogólną i to będzie jego jedyne zadanie, ewentualnie ustawi źródło danych. Raz będzie to plik, a raz baza. Z tą wykładnią modelu jaką obecnie podałeś mogę więc się zgodzić. Pisząc jednak o świadomości kontrolera co wywołuje mimowolnie narzucasz odbiorcy myślenie w formie istnienia funkcji kontrolera, która zajmuje się określonym wariantem, czyli dla mnie i zapewne wielu osób zamiast get(param) -> getXML(param), getDB(param). I stąd nasze nieporozumienie. Można powiedzieć, że nie mówiliśmy niewystarczająco abstrakcyjnie (IMG:style_emoticons/default/winksmiley.jpg)

Co do tego czy kontroler wie co może być źródłem danych, to on nie musi tego wiedzieć. Tę świadomość ma klasa związana z konfiguracją. Kontroler ma do niej dostęp i wpływać może na nią, co skutkuje także wpływem na używanie przez model określonego źródła danych. Instalacja "pluginu" jest, przykładowo, poinformowaniem konfiguracji "hej... pojawił się nowy typ źródła danych. Jakby co poinformuj odpowiednie kontrolery, że mogą mnie wybrać, a modele mają przeciążone pewne funkcje". To, jak to będzie rozwiązane to już osobna sprawa (IMG:style_emoticons/default/smile.gif) Może to być choćby zwykły dopisek w pliku konfiguracyjnym, że w ścieżce takiej a takiej jest plik, który można użyć i służy on do obsługi innego źródła danych niż dotychczasowo znane. Myślę, że opisałem moje podejście zrozumiale, bo nie wiem czy można jeszcze inaczej. Tak chyba było najprościej. Może co prawda zajść sytuacja, że ma coś w konfigu, ale user perfidnie wywalił pliki odpowiadające za dany typ źródła danych. No ale od tego jest system obsługi błędów (IMG:style_emoticons/default/winksmiley.jpg)

Ogólnie widzę, że zaczynamy już dochodzić do consensusu w sprawie terminologii i postrzegania wielu aspektów, a co za tym idzie, mniej pojęć i zdań niejednoznacznych (IMG:style_emoticons/default/smile.gif)

EDIT: Bym zapomniał... Wspomniane

Chodzi mi o to, żeby on wywołał wyslij(typ wysyłki, dane_z_formularza)

Może ostatecznie być rozwiązane na dwa sposoby:
1) Kontroler dowiaduje się z klasy konfiguracji co mamy za źródła danych i jakie z nich jest domyślne (tak odbieram teraz Twoje podejście)
2) Informacje o źródle danych pobiera sam model, też z konfiguracji, przykładowo podczas wywołania konstruktora (to podejście podzielam ja) i w ten sposób nie jest potrzebne określanie typu wysyłki.
Efekty będą identyczne.

Ten post edytował thek 16.10.2009, 11:09:56