[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

[jmail]

dr4ko czekaj czekaj. czy to nie jest tak, że model to jest własnie baza danych? przecież DAL jest właśnie warstwą programowalną modelu. to do niej kontroler musi wysłać dane i powiedzieć co z nimi zrobić. Nie możesz mówić, że kontroler ma być nieświadomy modelu bo on musi model poprosić o konkretne dane, albo konkretne dane mu przekazać.

Z widokiem masz rację bezdyskusyjnie.

Kontroler jest odpowiedzialny za odczyt danych z bazy danych (utworzenie modelu) i przekazanie ich do warstwy widoku (interfejsu użytkownika). Gdy użytkownik wybierze pokaż kolejne, wtedy odwołanie jest przekazywane do kontrolera, który ponownie pobiera dane i przekazuje do widoku tą samą drogą.

co z resztą jest zbieżne z tym czego mnie na uczelni uczono

Praktycznie każda aplikacja WWW korzysta z baz danych - operacje na bazach stanowią modele danych. Szablony HTML odpowiedzialne za wygląd i wyświetlanie danych są częścią widoków (np. Smarty). Kod odpowiedzialny za wykonanie określonych operacji (spinający wszystko razem) tworzy sterowniki.

Poza tym jak to sobie wyobrażasz? Kontroler niświadomy modelu to co? Podaj mi jakiekolwiek dane a ja z nimi nie będę wiedział co zrobić? oO Przecież to się kupy logicznej nie trzyma oO

[dr4ko]

dr4ko czekaj czekaj. czy to nie jest tak, że model to jest własnie baza danych? przecież DAL jest właśnie warstwą programowalną modelu. to do niej kontroler musi wysłać dane i powiedzieć co z nimi zrobić. Nie możesz mówić, że kontroler ma być nieświadomy modelu bo on musi model poprosić o konkretne dane, albo konkretne dane mu przekazać.

Może źle się wyraziłem. Kontroler nie powinien być świadomy charakteru modelu. Co kontrolerowi do tego czy wysłać maila potwierdzającego czy nie? Albo co kontrolerowi do tego czy dane są pobierane z bazy czy z pliku xml? Kontroler reaguje na sygnał z UI, sprawdza jego poprawność i przekazuje dalej, nic poza tym. Po prostu cała logika biznesowa powinna być zawarta w modelu. Może bardziej obrazowy przykład:

Użytkownik za pomocą programu chce włączyć drukarkę. Klika przycisk. Informacja wędruje do kontrolera który sprawdza czy to na pewno dobry przycisk. Jeśli tak wywołuje komendę "włącz drukarkę" na modelu który w tym przykładzie jest fizyczną drukarką i oczekuje na informację zwrotną czy drukarka się włączyła czy nie. I nic poza tym, kontroler nie zajmuje się inicjalizacją wszystkich podzespołów i protokołów drukarki, drukarka robi to sama. Dzięki temu gdy kupimy nową drukarkę innej firmy nie musimy przepisywać całego kontrolera, tylko podpinamy ją pod już istniejący i będzie działała jak trzeba bo cała logika specyficzna dla danej drukarki jest zamknięta w samej drukarce, czyli naszym modelu.

Mam nadzieję że to co napisałem jest zrozumiałe (IMG:style_emoticons/default/smile.gif)

Aha. Co do modelu będącego jednocześnie DAL czyli bazą danych. W prostych aplikacjach to może działać ale w dużych nie ma szans. Prosty przykład z systemu który rozwijamy w mojej firmie - mamy kilka rodzajów użytkowników, każdego opisuje około 5 tabel, z których tylko 3 są wspólne. Powiedz mi jak to obsłużyć korzystając tylko z DAL (IMG:style_emoticons/default/tongue.gif)

Ten post edytował dr4ko 15.10.2009, 15:27:05