nicht angemeldet
ich denke, beide ansätze haben ihre daseinsberechtigung.
wie du schon sagst, ist es eine frage ob der controller der 'oberchef' ist, oder nur ein organ um die daten zu ereignissen zu holen.
im reinen gui umfeld läßt sich auf ereignisse ja anders eingehen als in einer web transaktion.
wenn man z.b. mal ein panel mit visual studio und vb aufbaut, hat man den controller als oberste instanz mit der ereignissteuerung der controls. die view ist mit den controls verbunden.
bei einer web transaktion siehts ja etwas anders aus:
der browser schickt was weg, einen request an den server. hieraus entsteht eine andere anzeige an dem browser.
der server muß diese seite erstellen. eigentlich bräuchte in vielen fällen nur ein teil des bildschirms geändert zu werden. dies ließe sich mit der (verfluchten) frame technik erreichen. oft wird aber der ganze bildschirm neu aufgebaut. es muß also mehr information als eigentlich notwendig an den browser geschickt werden.
zudem ist der controller zweigeteilt: einmal als auslöser auf dem browser, dann als handler auf dem server. (hier versucht sich ja m$ mit seinem .net). daher muß der browser-controller teil ja im html vom server mitgeneriert werden.
ich baue mir hierfür eine objektstruktur auf dem server auf, welche alle daten und methoden enthält. im html wird dann bezug auf diese struktur genommen.
z.b. $seite = new seite($_request)
im html steht dann z.b. $seite->zeigeDatum()
hier habe ich 2 dateien: eine .php mit der applikationslogik und eine htm mit der darstellung.
diese trennung hat also die view herausgezogen. der controller befindet sich aber in beiden dateien.