Model View Controller

Entwurfsmuster für die Android-Applikationen
Gepostet von Boris Dudelsack am 31 Januar, 2019

Geschichte und Konzepte

Das Model View Controller Entwurfsmuster ist eines der ältesten Muster in der GUI-Entwicklung, welches innerhalb der Firma Xeroc PARC entwickelt wurde. Gedacht war das im Jahre 1987 von Steve Burbeck erstmals vorgestellte Programm für die Programmiersprache Smalltak-80.

Dieses Entwurfsmuster zwichnet sich vor allem dadurch aus, dass bei der Entwicklung besonders Wert auf die Einfachheit gelegt wurde. Die View und Model werden mit einem Baustein namens Controller verbunden. Der Controller ist für die Verarbeitung der Eingaben des Benutzers zuständig, das Model für die Geschäftslogik und die View hat die Aufgabe den Benutzer über die Veränderungen des Zustandes zu benachrichtigen.

Zwischen der View und dem Controller besteht eine 1-zu-1 Beziehung. Daraus resultiert, dass beide die Möglichkeit haben auf einander und auch auf das Model zu zugreifen. Dadurch wird gewährleistet, dass das Programmieren für den Entwickler vereinfacht wird, schafft aber andererseits eine starke Kopplung zwischen den Komponenten.

Man unterscheidet in dem Kontext des Model View Controllers zwischen dem passiven oder dem aktiven Model. Während bei dem passiven Model Veränderungen nur durch das aktive Handeln des Benutzers generiert werden können. Bei dem aktiven Model hingegen kann das Model sich selbst verändern. Somit ist die Unterscheidung darauf begründet, ob das Model sich selbst signalisieren kann, dass der Zustand sich verändert hat. In den folgenden Kapitel wird dieser Unterschied genauer erläutert.

Model-View-Controller State and Message Sending (Krasner und Pope, A Cookbook for using the Model-View-Controller User Interface Paradigm in Smalltalk-80, Jan. 1988)

Das passive Model

Das passive Model ist das vermeintlich simpelste: Die Änderungen an dem Model werden ausschließlich durch die Benutzereingaben generiert. Da der Controller die Eingaben verarbeitet, werden dabei auch die Änderungen der View durch den Controller signalisiert. Das Model übernimmt in diesem Szenario keine Verantwortung für die Kommunikation der Änderungen. Dabei ist der größte Vorteil dieses Models, dass es sich weder der Existenz der View noch der des Controllers bewusst ist. Daraus resultiert eine komplette Unabhängigkeit und Testbarkeit des Models.

Model View Controller (passives Model) - Kommunikationsdiagramm
Model View Controller - Klassendiagramm
Model View Controller - Ablaufdiagramm

Das aktive Model

Jedoch lassen sich keinesfalls alle Fälle mit einem passiven Model lösen. Besonders im Falle einer Asynchronität muss das Model ein Mechanismus besitzen die View zu benachrichtigen, dass Änderungen vorhanden sind. In diesem Falle ist es Unabdingbar, dass das Model mit der View kommunizieren kann. Diese Kommunikation kann entweder durch eine direkte Verbindung mit der View oder auch durch einen Callback-Mechanismus erfolgen. Besonders die Kommunikation durch einen Callback Mechanismus hat dabei den Vorteil, dass die einzelnen Komponente stark entkoppelt werden

Model View Controller - Ablaufdiagramm (aktives Model)
Model View Controller - Ablaufdiagramm unter Android
Model View Controller (aktives Model) - Kommunikationsdiagramm

Die Besonderheiten bei der Umsetzung unter Android

In der Ursprungsversion des Entwurfsmuster ist der Controller für die Verarbeitung der Eingaben verantwortlich während die View lediglich für das Anzeigen des aktuellen Zustands zuständig ist. Unter Android lässt sich es in dieser Form jedoch nicht realisieren, da die Eingaben des Benutzers durch die View abgefangen werden.

Die Activity unter Android beinhaltet in sich bereits die View und auch den Controller, was dazu führt, dass das Entwurfsmuster des MVC für die Android-Umgebung als eher unpraktsch angesehen werden kann.

Nichtsdestotrotz werden im folgenden Verlauf der Arbeit zwei Realisierungsansätze für Android möglichst umfangreich ausprobiert. Dabei wird in beiden Realisierungsversuchen von einem passiven Model ausgegangen, um die Umsetzung des Versuches zu vereinfachen.