MVC, a co z całą resztą? Opcje

[Asmox]

MVC jest oczywiście jest wzorcem na ściąganie danych i obróbkę i wyświetlenie. Ale co z całą resztą? Można napisać klasy do tylko potrzebnych rzeczy, ale gdzie je poumieszczać i gdzie dawać ich wywołania?
Powiedzmy, że mam taki układ folderów:

Kod

application
|- models
|- views
|- controller

I napisałem sobie klasę powiedzmy do obsługi sesji. Gdzie ją umieścić i gdzie wstawiać kod operujący na tej klasie? Mam na myśli bardziej ogólne rozwiązanie, bo nie wiem co robić z różnymi dodatkowymi klasami, które nie mają nic wspólnego z MVC, ale są mi równie potrzebne

[thek]

Asmox... Najprościej i najogólniej rzecz ujmując można napisać tak:
Model - operuje na danych, różnych jego formach, manipuluje nimi.
View - służy do prezentacji danych.
Controller - steruje przepływem informacji i procesami aplikacji.

Rzuciłeś sesją. Ma ona gdzieś pokazywana? Nie. Wylatuje widok. Czy sesja w jakiś sposób steruje przepływem informacji w aplikacji? Nie sama w sobie jest informacją i sama siebie kontroluje oraz modyfikuje. Jest więc warstwą operacji na danych - jest więc modelem.

Rzucasz filtry przykładowe? Proszę bardzo... Zwróć uwagę, że to nic innego niż zmiana, manipulacja danymi, nie wykraczająca dalej. Nie są one bowiem ani wyświetlane, ani nie jest wymagana ingerencja zewnętrzna w ten proces. Dostajesz polecenie: weź A i zrób z tego B. Znowu kłania się warstwa modelu. Warstwy mogą ze sobą współpracować.Przykład? Widok wyświetla pewne informacje, które idą do Kontrolera. Ten decyduje na podstawie działań użytkownika, że Model musi zmienić strukturę danych do innej formy i przekazać ją do Widoku ponownie.Na tym właśnie polega MVC. Rozgraniczanie obsługi pewnych czynności i funkcjonalności do wybranych warstw za nie odpowiedzialnych.

Tak jak powiedział Zyx... Nie zrozumiesz, lub zrobisz to w sposób niekoniecznie dobry jeśli zaczniesz naukę "od dupy strony" (IMG:style_emoticons/default/winksmiley.jpg) Nie buduje się samolotu, nie mając pojęcia o aerodynamice. Tak samo zrozumienie wzorców projektowych bez zrozumienia czym jest i z czym się je programowanie obiektowe, jest zwyczajnie skakaniem do wody bez znajomości dna. Niektórym się uda złapać ideę "na czuja" ale część złamie kręgosłup.

Ja przez naprawdę długi czas nie wiedziałem o czymś takim jak wzorce projektowe. Ale nieświadomie je stosowałem bo wychodziły naturalnie podczas pisania. gdy zacząłem je poznawać po prostu usystematyzowałem wiedzę i tyle. Różnica jednak polegała na tym, że zanim zacząłem je stosować świadomie, miałem już kilka lat nauki obiektówki w C++ i liźnięcie Javy, która jest bardziej rozbudowana w tych dwóch językach niż w PHP. Tam specyfikatory dostępu, dzielenie zakresów działania, dziedziczenie, hermetyzacja są naturalnym elementem języka. Obiektówki się na tej bazie można uczyć i zrozumienie potem tego co w PHP lub dowolnym innym języku z nią próbują zrobić jest analogiczne. Są różnice, ale znając ogólne zasady widzisz tylko je w porównaniu do standardu. I tylko ich się uczysz. Dzięki temu nie uczysz się standardów kilku języków, ale jeden i różnice w stosunku do niego. Jest to prostsze.