Oha,

das Problem am MVC Model ist dass die einzelnen Bestandteile nicht sauber definiert sind. Es bleibt ein Interpretationsspielraum. So liest man immer wieder verschiedene Ansätze. Hab schon gelesen das Model sei PHP, View sei HTML und der Controller sei Javascript.

Interessant wirds, wenn eine Viewclass verschiedene Moddels darstellen kann und schon haben wir den Salat: Das ist pure OOP-Praxis, alles was ein Moddl braucht, steckt in den Attributen und wir haben wiederverwertbaren Code ;)

Ich sehe das Model als die Daten, der Controller ist die Datenverknüpfung bzw. Verarbeitung und der View sind die Templates, die bei der Darstellung helfen.

Auch das Template könnte in einem der Atribute namentlich benannt werden.

Javascript wäre eine vierte Ebene.

Warum nicht die gesamte Businesslogik per JS abwickeln, der Server wird nur noch gebraucht, wenn es was Wichtiges zum Speichern oder anderen Clients mitzuteilen gibt.

Im Endeffekt sind Software Patterns oder Definitionen total irrelevant. Wenn du es jedoch mit Funktionen schaffst einen sauberen und wiederverwendbaren Code hin zu bekommen, dann brauchst du keine Software Pattern.

FullAck!