publish and discover academic work ...

Die ganze Welt steht hinter MVC

MVC - Die Welt steht hinter MVCDie ganze Welt findet MVC (Model-View-Controller) klasse. MVC macht immer Sinn. Aber macht MVC wirklich immer Sinn und ist MVC wirklich immer notwendig? Es gibt keineswegs ein Mangel an JavaScript MVC (Model-View-Controller) Architekturen. Zu den wohl am besten bekannten gehören etwa Backbone und andere wie Spine, Agility, Knockback. Zusätzlich zu den MVC Frameworks gibt es auch sogenannte MV (Modell-Views) Varianten. Lustigerweise sind alle diese Frameworks sehr wohl bekannt und genießen eine hohe Popularität. Im Moment ist Backbone beispielsweise, das am siebent häufigste heruntergeladene Repository in GitHub, das sich Entwickler regelmäßig ansehen. Entwickler lieben einfach MVC.


MVC: Model View Controller

Was macht MVC also so reizvoll, insbesondere für JavaScript, das ja immer noch primär im Client verwendet wird? Wenn Sie mit Software Architekturen vertraut sind, ist das Modell sehr verständlich: Das Modell hält die Daten, die View ist eine Art Sicht auf die Daten und der Kontroller stellt die Operationen auf den Daten zur Verfügung. Ganz einfach nicht wahr? Wenn Sie sich mit Serverapplikationen auskennen, wird Ihnen MVC nicht fremd vorkommen. In der objektorientierten Programmierung ist dieses Patter praktisch immer enthalten. Es gibt mittlerweile sehr bekannte MVC Framworks für Programmiersprachen wie Java, .NET, Python, PHP usw. Das Pattern selbst war zuvor in Smalltalk implementiert, nachdem es in den 70er Jahren von Trygve Reenskaug erstmals eingeführt wurde. Wichtig ist jedoch zu bemerken, dass die MVC Architektur nur in Verbindung mit OOP (Object oriented programming) entstanden ist. Es steht also in direkter Verwandtschaft mit der Objektorientierung. Aufgrund dessen ist es überhaupt keine Überraschung, dass viele von uns ohne Zweifel denken, dass MVC Architekturen immer sinnvoll sind.

MVC und JavaScript

JavaScript ist jedoch nicht wirklich objektorientiert. Wir können zwar eine objektorientierte Struktur bauen, aber es ist sehr aufwändig und nur mühsam zu programmieren. Aus diesem Grund ist die Eignung von MVC in JavaScript nur für bestimmte Usacase gewährleistet. Für die Dateneingabe, für das Management von Inhalt (CMS Systeme) und Situationen, in den wir klare „Modelle“ einsetzen können, scheint es sehr gut zu funktionieren. Aber in den Fällen, in den beispielsweise der Status einer Applikation eher strukturlos ist und in Applikationen in den viele Benutzerinteraktionen stattfinden bevor sich irgendwelche Daten verändern oder in Applikationen in denen sehr komplexe Widgets eingesetzt werden, ist es nicht immer klar ob MVC die richtige Wahl ist. Im aller schlimmsten Fall, ist Ihre Seite der JavaScript lastig und zusätzlich überwiegend statisch, dann können Sie MVC vergessen! Es gibt Ihnen kein Vorteil, wenn Sie Unmengen an Seiten- und Datenoperationen durchführen und diese nach einem Reload der Seite sofort wieder verlieren.

MVC ist nicht für Webentwickler gedacht!


Der Grund warum ich hier über MVC oder irgendwelche anderen Architektur Patterns spreche ist einfach die Tatsache, dass alle diese Konzepte nicht für uns Webentwickler gedacht sind. Wir können die meisten gängigen Architektur Patterns auf Design Patterns zurückführen, die 1995 zum ersten Mal publiziert wurden. Diese Design Patterns wurden für Entwickler, die in erster Linie Software entwickeln, gedacht und nicht für Entwickler, die schlicht und einfach Menüs zum Klicken und schließlich Anzeigen der Daten gestalten. Diese Pattern landeten schließlich im Back-End und gingen JavaScript schließlich voran.

MVC gehörte dennoch zu den alten Methoden, die sofort Sinn machte. Weil eben Elemente wie das UI gut aufgehoben waren und es einfach auf das Front-End anzuwenden ist. Weil jedes Pattern, das wir für eine bestimmte Aufgabe einsetzten möchten, ein wenig frisiert werden muss, um es auf den Kontext anwenden zu können, ist MVC ein guter Startpunkt. Aber es ist nicht die einzige Option die wir zur Verfügung haben.

Fairerweise muss ich hier auch die Event-Driven Architekturen erwähnen. Event basierte Pattern setzten wir überall im JavaScript Code ein, auch in Kombination mit MV Patterns. Sie funktionieren überall dort gut, wo viel Datentransfer stattfindet. Für Objekte haben wir unsere getter- und setter-Methoden [und bald auch Object.observe()], um Daten zu manipulieren, Event zu entkoppeln und vieles mehr. Der Wert ist jedoch, dass die entkoppelten Events nicht nur für Objekte eingesetzt werden, sondern auch für Manipulation des DOM, Server Interkationen oder anderen Events eingesetzt werden können. Es muss aber nichts davon in ein Modell-View-Controller gepackt werden um die Funktionalität zu gewährleisten.

Das nackte Objekt Pattern hat eine direkte Verwandtschaft mit MV und es ist nicht unfair diese Variante als Presentation-Abstract-Control zu bezeichnen. Dieses Pattern eignet sich vor allem für komplexe Widgets, die ihre Daten selbst verwalten und rendern. Die visuelle Repräsentation solcher gewaltigen Widgets, bildet jedoch direkt die Daten die es enthält ab.

Das dritte Pattern, das jedoch noch einer gründlichen Prüfung unterzogen werden muss, ist das Pipeline Pattern. Für Entwickler, die mit jQuery arbeiten, sollte dieses Pattern bekannt sein oder für jeden der viel mit Callbacks arbeitet. Pipelines führen Operationen zusammen um ein gemeinsamen Zustand zu erwirken für die visuelle Repräsentation der Daten oder für die Datenhalten selbst (oder beides). Das interessante dabei ist, dass wir dieses Pattern sowohl synchron als auch asynchron nutzen können, wie z.B. das Anwenden von globalen Funktionen um Objekte zu initialisieren, zu rendern oder eine Seite aufzubauen um schließlich instanzspezifische Funktionen auszuführen, die auf die Nutzerinterkationen warten, diese Validieren, versuchen sie zu speichern und die Daten wieder erneut rendern.

Fazit


Mit allen diesen Patterns, genauso wie mit MVC oder irgendwelchen anderen Pattern, müssen Sie sich überlegen, ob Ihre Applikation eng oder lose gekoppelt werden soll. Architekturen wie etwa die genannten „nacketen Objekte“ sind absolut übertrieben. Event Driven Applications (EDA) sind zwecklos, wenn der Großteil Ihres Codes für die Initialisierung und den Aufbau zuständig ist.

Trotz der ganzen Kritik, ist es immer noch besser ein Framework wie „Backbone“ zu nutzen als gar nichts. Wenn Sie jedoch an einem Applikation arbeiten und feststellen, dass Ihre Anwendung in ein anderes Pattern wesentlich besser hineinpasst, dann sollten Sie sich nicht scheuen es auch einzusetzen. Leider, werden Sie (nach meiner Erfahrung) für die meisten Patterns nichts passenderes, zugänglicheres und robusteres wie „Backbone“ finden können. Aber noch wichtiger ist, wenn Sie sich nun hinsetzen und ein neues JavaScript Framework entwickeln, würden Sie uns allen ein Gefallen tun, wenn Sie eine Alternative zu MVC implementieren würden. Was auch immer Sie tun und welche Applikation Sie auch entwickeln, bedenken Sie, dass es wichtiger ist, Möglichkeiten zur Verfügung stellen um die Architektur zu verbessern als Wege bereitstellen um den Code selbst zu verbessern.
  • derhov derhov,
  • 03 Dezember 2012, 00:40
  • 1

Kommentare (0)

RSS zusammenklappen / ausklappen

Kommentar schreiben

Ihr Name
Sie sind ein Gast, Sie dürfen keine HTML-Tags verwenden
Bitte geben Sie die Zeichen in das folgende Feld ein