Tach!

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.

Wenn der Controller in Javascript geschrieben ist, dann handelt es sich in dem Fall wohl um eine SPA (Single Page Application) die sich vorwiegend im Browser abspielt und die Serverseite nur zur Datenspeicherung verwendet. Allerdings kann die Serverseite ihrerseits auch wieder das MVC-Model verwenden, besonders dann, wenn die API etwas umfangreicher geworden ist. Die serverseitigen Views geben dann zum Beispiel XML oder JSON statt fertigem HTML aus.

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. Javascript wäre eine vierte Ebene.

Oder auch nicht. Dieser Satz sieht mir jedenfalls wieder nach klassischer Web-Anwendung aus, die Javascript für mehr oder weniger nur Effekte und kleine Hilfsmittel auf dem Client verwendet.

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.

Ja, man muss dann nicht nur die Geschäftslogik in Code formulieren sondern auch noch Gedanken um die Architektur machen, die man sich beim Anwenden von bewährten Models größtenteils sparen kann. Vorausgesetzt man hat schon genügend Erfahrung mit deren Umgang gesammelt.

dedlfix.