Ist der Model-View-Controller am Frontend tot?

Immer mehr Front-End-Entwickler verwenden unidirektionale Architekturen. Wie sieht die Zukunft des klassischen MVC-Ansatzes (Model-View-Controller) aus?

Um zu verstehen, wie wir zu diesem Punkt gekommen sind, wollen wir zunächst die Entwicklung der Front-End-Architektur untersuchen.

In den letzten vier Jahren habe ich an vielen Webprojekten gearbeitet und viel Zeit damit verbracht, Frontends zu entwerfen und Frameworks in diese zu integrieren.

Vor 2010 wurde JavaScript - die Programmiersprache, in der jQuery geschrieben wurde - hauptsächlich zum Hinzufügen von DOM-Manipulationen zu herkömmlichen Websites verwendet. Die Entwickler schienen sich nicht sonderlich um die Architektur selbst zu kümmern. Dinge wie das aufschlussreiche Modulmuster waren gut genug, um unsere Codebasen zu strukturieren.

Unsere aktuelle Diskussion über Front-End- und Back-End-Architektur fand erst Ende 2010 statt. Zu diesem Zeitpunkt nahmen Entwickler das Konzept einer einseitigen Anwendung ernst. Dies war auch der Zeitpunkt, an dem Frameworks wie Backbone und Knockout populär wurden.

Da viele der Prinzipien, nach denen diese Frameworks aufgebaut waren, zu dieser Zeit noch recht neu waren, mussten ihre Designer anderswo nach Inspiration suchen. Sie liehen sich Praktiken aus, die für die serverseitige Architektur bereits gut etabliert waren. Zu diesem Zeitpunkt umfassten alle gängigen serverseitigen Frameworks eine Art Implementierung des klassischen MVC-Modells (aufgrund seiner Variationen auch als MV * bekannt).

Als React.js zum ersten Mal als Rendering-Bibliothek eingeführt wurde, verspotteten viele Entwickler es, weil sie den Umgang mit HTML in JavaScript als kontraintuitiv empfanden. Sie übersahen jedoch den wichtigsten Beitrag, den React auf den Tisch brachte - die komponentenbasierte Architektur .

React hat keine Komponenten erfunden, aber diese Idee ist noch einen Schritt weiter gegangen.

Dieser große Durchbruch in der Architektur wurde sogar von Facebook übersehen, als sie React als "V in der MVC" bewarben.

Nebenbei bemerkt, ich habe immer noch Albträume, nachdem ich eine Codebasis überprüft habe, bei der Angular 1.x und React zusammenarbeiten.

2015 brachte uns eine große Veränderung in der Denkweise - vom bekannten MVC-Muster zu den unidirektionalen Architekturen und Datenflüssen, die von Flux und Functional Reactive Programming abgeleitet wurden und von Tools wie Redux oder RxJS unterstützt werden.

Wo ist bei MVC alles schief gelaufen?

MVC ist wahrscheinlich immer noch der beste Weg, um mit der Serverseite umzugehen. Es ist eine Freude, mit Frameworks wie Rails und Django zu arbeiten.

Die Probleme ergeben sich aus der Tatsache, dass die Prinzipien und Trennungen, die MVC auf dem Server eingeführt hat, nicht mit denen auf dem Client identisch sind.

Controller-View-Kopplung

Unten sehen Sie ein Diagramm, wie die Ansicht und der Controller auf dem Server interagieren. Es gibt nur zwei Berührungspunkte zwischen ihnen, die beide die Grenze zwischen Client und Server überschreiten.

Wenn Sie auf dem Client zu MVC wechseln, liegt ein Problem vor. Controller ähneln dem, was wir als "Code-Behind" bezeichnen. Der Controller ist stark von der Ansicht abhängig. In den meisten Framework-Implementierungen wird es sogar von der Ansicht erstellt (wie dies beispielsweise bei ng-controller in Angular der Fall ist).

Wenn Sie an das Prinzip der Einzelverantwortung denken, verstößt dies eindeutig gegen die Regeln. Der Client - Controller - Code wird mit sowohl dem Umgang Event - Handling und Geschäftslogik , auf einem bestimmten Niveau.

Fette Modelle

Denken Sie ein wenig über die Art der Daten nach, die Sie in einem Modell auf der Clientseite speichern.

Einerseits verfügen Sie über Daten wie Benutzer und Produkte , die Ihren Anwendungsstatus darstellen . Auf der anderen Seite müssen Sie den UI- Status speichern - Dinge wie showTab oder selectedValue .

Ähnlich wie beim Controller verstößt das Modell gegen das Prinzip der Einzelverantwortung, da Sie keine separate Methode zum Verwalten des UI-Status und des Anwendungsstatus haben .

Wo passen Komponenten in dieses Modell?

Komponenten sind: Ansichten + Ereignisbehandlung + UI-Status .

Das folgende Diagramm zeigt, wie Sie das ursprüngliche MVC-Modell tatsächlich aufteilen, um die Komponenten zu erhalten. Über der Linie bleibt genau das, was Flux zu lösen versucht: Verwalten des Anwendungsstatus und der Geschäftslogik .

Mit der Popularität von React und komponentenbasierter Architektur haben wir den Aufstieg unidirektionaler Architekturen zur Verwaltung des Anwendungsstatus gesehen.

Einer der Gründe, warum diese beiden so gut zusammenpassen, ist, dass sie den klassischen MVC-Ansatz vollständig abdecken. Sie bieten auch eine viel bessere Trennung von Bedenken beim Erstellen von Front-End-Architekturen.

Dies ist jedoch keine Reaktionsgeschichte mehr. Wenn Sie sich Angular 2 ansehen, wird genau dasselbe Muster angewendet, obwohl Sie verschiedene Optionen zum Verwalten des Anwendungsstatus haben, z. B. ngrx / store.

Es gab eigentlich nichts, was MVC auf dem Client hätte besser machen können. Es war von Anfang an zum Scheitern verurteilt. Wir brauchten nur Zeit, um das zu sehen. Durch diesen fünfjährigen Prozess entwickelte sich die Front-End-Architektur zu dem, was sie heute ist. Und wenn Sie darüber nachdenken, sind fünf Jahre nicht so lange, bis Best Practices entstehen.

MVC war am Anfang notwendig, weil unsere Front-End-Anwendungen immer größer und komplexer wurden und wir nicht wussten, wie wir sie strukturieren sollten. Ich denke, es hat seinen Zweck erfüllt und gleichzeitig eine gute Lektion darüber erteilt, wie man eine gute Praxis aus einem Kontext (dem Server) auf einen anderen (den Client) anwendet.

Wie sieht die Zukunft aus?

Ich glaube nicht, dass wir bald für unsere Front-End-Apps auf die klassische MVC-Architektur zurückkommen werden.

Da immer mehr Entwickler die Vorteile von Komponenten und unidirektionalen Architekturen erkennen, wird der Schwerpunkt auf der Entwicklung besserer Tools und Bibliotheken liegen, die diesen Weg einschlagen.

Wird diese Art von Architektur in fünf Jahren die beste Lösung sein? Es besteht eine gute Chance, dass dies geschieht, aber andererseits ist nichts sicher.

Vor fünf Jahren hätte niemand vorhersagen können, wie wir heute Apps schreiben würden. Daher denke ich nicht, dass es jetzt sicher ist, die Wetten für die Zukunft zu platzieren.

Das ist alles! Ich hoffe, es hat Ihnen Spaß gemacht, dies zu lesen. Ich freue mich über Ihr Feedback unten.

Wenn Ihnen der Artikel gefallen hat, klicken Sie auf das grüne Herz unten und ich werde wissen, dass meine Bemühungen nicht umsonst sind.