Witam serdecznie.
Nie wiem czy nie do końca zrozumiałem tutaj logikę MVC ale mam kilka pytań dotyczących widoku i modelu.
Ciag wywołania strony wygląda u mnie tak:
-.htaccess przekierowuje na index.php
-tam inicjuje 'router' i wg. danych na wejściu (GET i POST) dobieram odpowiedni kontroler i akcję
-inicjuje kontroler w nim uruchamiam dana akcję (czy tez ta akcja powinna znaleźć się w modelu ? Już sam nie wiem ?)
-pobieram z modelu potrzebne do danej akcji dane z bazy danych
-inicjuje odpowiedni widok i przekazuje do niego zwrócone dane

1)Co jeżeli na stronie mogę mieć przykładowo stopkę ale mogę jej też nie mieć, skąd model ma wiedzieć czy ma pobierać potrzebne do niej dane czy też nie ? Chyba powinienem wywoływać pobranie tych danych dopiero przez widok gdy już wiem co dany widok zawiera i czego używa ?
2)Do czego tak właściwie jest mi tutaj potrzebny model, jest to jakaś kolejna warstwa abstrakcji, ale tak naprawdę dlaczego jest mi niezbędna ? jaka logika powinna się w nim znaleźć oprócz odczytywania danych z bazy danych, chyba nie poprawne jest przekazywanie listy danych do przekazania z kontrolera ?

Troszkę się rozpisałem, ale nie chciałem pozostawiać żadnych niedomówień.

Tu jest właśnie różnica pomiędzy MVC i MVP.
W MVC było by tak: Kontroler wywołuje Widok, Widok wie co potrzebuje i wywołuje odpowiedni dla siebie Model lub Modele.
W MVP: Kontroler (a właściwie Prezenter) wywołuje Widok i konieczny dla niego Model (lub modele) i troszczy się o to, by do Widoku trafiły wymagane dane z Modelu. Musi on pośredniczyć w tej wymianie, gdyż Widok sam z siebie nie ma połączenia z Modelami inajczęściej nic o nich nie wie. Tyko wymaga określonych danych.

Tak więc w sieci szumne pisanie o MVC nie ma w zasadzie racji bytu i spotyka się je w zasadzie jedynie w aplikacjach desktopowych. Sieć ma całość akcji w obrębie jednego żądania i koniec. Każde żądanie jest więc w sumie kolejnym procesem, a nie jednym ciągłym.

Jestem pod wrażeniem spójności wypowiedzi. Naprawde, nie spodziewałem się ze tak szybko będziesz w stanie tak prosto i przejrzyście mi to wyjaśnić. Dobrze wiedzieć że próbuje zaimplementować MVP zamiast MVC

Jeszcze tylko pytanie czym powinien być tak po prawdzie Model ? Cos w stylu ORM'a zeby zamaskować zapytania SQL ? Jeżeli tak to już wszystko stało się dla mnie jasne.

Proszę jeszcze tylko o tę jedna odpowiedź i serdecznie dziękuję.

Nawiązując więc do pytań...
ad 1) Jeśli wywołujesz określony Widok, to z reguły Kontroler wie o tym, czego on potrzebuje i takie funkcje Modelu/Modeli wywołuje by uzyskać wymagane dane. Jako że zdarzają się inteligentne, interaktywne Widoki to można oczywiście spotkać sytuacje, gdy w jego wnętrzu będzie wywołanie określonej metody, określonego modelu obwarowanego warunkami zapewne. Ale jest to wtedy gmatwanie Widoku celem uproszczenia Kontrolera. Przenosimy więc to co by było w Kontrolerze do wnętrza Widoku - nic więcej. To co proponujesz to faktycznie MVP, ale widzę, że chęć uniezależnienia Widoku od Kontrolera skłania Cię do myślenia kategoriami nie MVP, ale MVC własnie, bo tak zachowują się normalnie aplikacje desktopowe. A skąd Model ma wiedzieć czy jest stopka czy nie? Ano ma mu to w tym wypadku jasno i klarownie Prezenter powiedzieć

ad2) Model to warstwa danych i ich obróbki. Każda część MVC ma swoje własne zadania i cele. Najprościej ujmując:
Kontroler obsługuje żądanie i decyduje co należy zrobić, a więc jaki Widok i/lub Model wywołać.
Model służy do interakcji z danymi oraz ich obróbką. Dowolnego typu i pochodzenia. Nieważne czy to będzie plik, RDBMS, stream czy cokolwiek innego. On sie zajmuje tylko źródłem danych i jego ewentualnym przetworzeniem do wymaganego formatu.
Widok to warstwa odpowiedzialna za prezentację danych. Może to być strona, ale także odpowiednio sformatowany XML wypełniony przygotowanymi przez Model danymi czy jakaś faktura pdf.
Wiele osób bardzo często myli zadania tych 3 warstw przeplatając je między sobą. Zauważ, że wywołanie Kontrolera poprzez router już mu nakazuje pewne rzeczy i można określić czy pewne elementy będą czy też nie. To wystarcza by Kontroler wywołał odpowiedni Widok i tym samym wiedział co tenże Widok potrzebuje, a czego nie. Dzięki temu wie jaki Model wywołać i o co go poprosić by potem do Widoku wysłać.

A czym powinien być Model? Warstwą, która udostępnia mechanizmy operujące na danych w sposób niezalezny od tego co "w bebechach". Zauważ, że możesz pracować raz na plikach, innym razem na bazie, a jeszcze innym razem na zasobach sieciowych gdzieś na krańcu świata. Dla Ciebie nie powinno być ważne z czym masz do czynienia i interfejs powinien być jednolity. Jeśli coś chcesz pobrać i zapisać, to nie powinieneś z góry userowi dać metod zapiszHtml, zapiszPdf, zapiszCośTam tylko jednolite Zapisz. To Model na podstawie kontekstu powinien się sam połapać co ma zrobić i w tym względzie jest ORMem, ale Model to nie tylko to. ORM jest tylko jedną z "implementacji" Modelu i sam Model ma znacznie szerszy zakres zadań. On powinien obsługiwać wszelkie zadania związane z pobieraniem, konwertowaniem, zwracaniem danych w dowolnym formacie na żądanie Widoku lub Kontrolera.