Kilka pytań odnośnie tworzenia aplikacji opartych o MVC:

1. Jaką funkcję spełnia dispatcher? Wyczytałem, że na podstawie danych otrzymanych z routera wywołuje odpowiednią akcję odpowiedniego kontrolera, w takim razie sprawdzenie czy da się wykonać tą konkretną akcje lub ewentualne sypnięcie błędem to też jego zadanie?

2. Jak odwoływać się do danych z routera? np. mam newsController ($kontroler z routera ma wartość 'news') i kontroler powinien utworzyć instancję klasy newsModel (znowu potrzeba wartośc $kontroler), najprościej chyba przekazać obiekt routera w konstruktorze kontrollera? dobrze myśle?

3. Jak obsługiwać dane $_POST przez kontroler, mój prosty router zwraca nazwe kontrollera, akcje do wywołania i ew. tablice z parametrami (wszystko z $_GET'a), na forum przeczytałem gdzieś, że kontroler nie powinien odwoływać się bezpośrednio do danych z tablic globalnych (właśnie np $_POST) więc jak to powinno działać?

Miałem więcej pytań ale zapomniałem -.- dopisze w razie potrzeby. Narazie prosiłbym o odpowiedzi na powyższe

Jak masz konkretną klasę newsController, to logiczne, że będzie ona wywoływała newsModel. Przecież newsController nie wywoła raczej blogModel. Zmieniając $kontroler w Routerze, zmienisz i model, i kontroler, i prawdopodobnie widok.

Jeśli chcesz poczytać o przekazywaniu obiektów, w poddziale Pro był temat podobny do "Globale, Singleton, Registry" - te slowa kluczowe pamiętam

A niby dlaczego? Kontroler/akcja może potrzebować całej baterii modeli.


edit:



To już zależy od implementacji. Osobiście uważam, że dispatcher zajmuje się uruchomieniem kontrolera, który z kolei wie jak wywołać akcje.




Lepszym rozwiązaniem jest obiekt Request, który będzie trzymał POST, GET, SERVER, blabla wraz z wewnętrznymi (internal) parametrami frameworka tj. nazwa kontrolera i akcji, zmienne. Router może się zając uzupełnieniem obiektu Request.



Najlepiej to ujednolicić parametry GET i POST do jednej tablicy, a osobno trzymać info o typie żądania.

Ta architektura którą opisałem jest dosyć jednolita dla całej gamy (nie tylko PHPowych) frameworków, więc coś w tym musi być. Dodatkowo trzyma się zasady single responsibility