Model-View-Controller (MVC) (SAP-Bibliothek - Model-View-Controller (MVC))

Model-View-Controller (MVC)

Verwendung

Das im User-Interface-Programmierumfeld weit verbreitete und bewährte Model-View-Controller (MVC) Design Pattern wird zu SAP Web Application Server 6.20 als Erweiterung des bisherigen BSP-Programmiermodells eingeführt. Durch diesen Controller-basierten Ansatz ist eine noch klarere Trennung zwischen Applikationslogik und Präsentationslogik in BSP-Applikationen gewährleistet. Gerade bei komplexen Anwendungen lassen sich grafische Benutzeroberflächen übersichtlich strukturieren und in logische Einheiten einteilen.

Der Einsatz des MVC Design Pattern bietet die folgenden Vorteile:

Vereinfachung der Strukturierung von BSP-Applikationen, da der View vom Controller und dem Model sauber getrennt sind. Dadurch wird nicht nur die Änderbarkeit von BSP-Applikationen erleichtert, sondern auch die Wartbarkeit wesentlich verbessert.

Möglichkeit, das Layout auch programmgesteuert zu erzeugen, d.h. variabel. Damit wird der HTML-/XML-Output also durch Programmcode statt einer Seite mit Scripting erzeugt.

Navigation über <bsp:goto>-Element und Aufrufen über <bsp:call>-Element. Die <bsp:goto>-Navigation hat gegenüber dem Redirect den Vorteil, dass kein zusätzlicher Netzverkehr stattfindet. Außerdem bleibt man im gleichen Workprozess, was Vorteile für das Anlegen von Objekten und Speicherplatz haben kann. Das Aufrufen über das <bsp:call>-Element ist variabler als das Einfügen über die INCLUDE-Direktive, da sie zur Laufzeit aufgelöst wird.

Mit der Aufruf-Möglichkeit über <bsp:call>-Elemente können Sie zusätzlich die Benutzeroberfläche in Komponenten aufteilen.

Performance-Optimierung aufgrund weniger Redirects.
Intuitive und leicht verständliche Oberfläche für die Anwendungsentwicklung.

Hinweis

Bisherige BSP-Applikationen, d.h. BSP-Anwendungen ohne MVC, sind unverändert lauffähig. Der Einsatz von MVC bringt jedoch bei komplexeren Anwendungen diverse Vorteile mit sich, siehe Einsatz von MVC für BSP.

Integration

Das MVC Design Pattern ist ab SAP Web Application Server 6.20 in das BSP-Programmiermodell und den Web Application Builder der Entwicklungsumgebung der ABAP Workbench (Transaktion SE80) integriert.

Funktionsumfang

Eine BSP-Anwendung kann, neben den bekannten Elementen wie Applikationsklasse, MIME-Objekt und Theme, aus einem oder mehreren Controllern und Business Server Pages bestehen. Eine BSP kann unterschiedliche Ausprägungen haben, entweder ist sie eine Seite mit Ablauflogik (wie bisher auch) oder ein View oder ein Seitenfragment:

Diese Grafik wird im zugehörigen Text erklärt

Innerhalb einer BSP-Applikation kann es mehrere Controller, mehrere Views, und mehrere Seiten mit Ablauflogik geben.

Controller

Ein Controller ist die Instanz einer zentralen Controller-Klasse. Im BSP-MVC-Umfeld ist jeder Controller direkt oder indirekt von der gleichen Basisklasse CL_BSP_CONTROLLER2 abgeleitet, wobei die zentrale Methode DO_REQUEST ist.

Zu jedem Controller gibt es eine URL. Diese ist von außen, z.B. über einen Browser, ansprechbar. Daher kann ein Controller als Einstieg in eine BSP-Anwendung eingesetzt werden. Die Abbildung von URL auf Controller-Klasse wird in der BSP-Anwendung festgelegt.

Ein Controller ist im MVC Design Pattern die kontrollierende Instanz, indem er als Steuerungsmechanismus fungiert. Er erfüllt dabei die folgenden Aufgaben:

Er sorgt für die Bereitstellung der Daten
Er ist für die Auswahl des richtigen Layouts zuständig
Er triggert die Daten-Initialisierung
Er führt die Eingabeverarbeitung durch
Er legt eine View-Instanz an und ruft sie auf

Auswahl des Layouts

Ein Controller wird i.d.R. für die Erzeugung des HTML-/XML-Outputs intern eine View-Instanz aufrufen. Der Controller kann einen View aufrufen, der über eine Factory-Methode angelegt wird. Hierbei kann zum Beispiel das Theme oder die Browser-Variante als Auswahlkriterium eingehen. Wenn ein Controller die Kontrolle an einen View abgibt, hat er die Möglichkeit, Attribute des Views zu setzen, und sollte dies auch tun. Diese Attribute können einfache Daten sein, oder eine Referenz auf ein (im Extremfall auch mehrere) Model(s). Eine Referenz auf den Controller wird automatisch übergeben.

Achtung

Ein Controller kann nur auf Views seiner eigenen Anwendung zugreifen.
Ein Controller kann jedoch die Verarbeitung an einen anderen Controller delegieren, und dieser Controller kann in einer anderen Anwendung liegen.

Ein Controller sollte nicht mit zu vielen Views arbeiten, weil die Verarbeitung aller dieser Requests an einer zentralen Stelle ankommt. Andererseits sollten alle Views, die die gleiche oder sehr ähnliche Eingabeverarbeitung haben, von einem Controller aus angesprungen werden.

Datenbereitstellung

Ein Controller hat zwar keine vordefinierten Attribute, die über generische Methoden gesetzt und gelesen werden können. Aber ein Controller sollte eine Methode init_attributes anbieten, die für das Füllen der Attribute zuständig ist. Es gibt eine Service-Methode, mit der das Füllen der Attribute erleichtert wird.

Eventhandling

Der Controller kümmert sich auch um das Eventhandling. Damit übernimmt er all die Aufgaben, die im bisherigen BSP-Programmiermodell von den Eventhandlern durchgeführt wurden: Er führt die Initialisierung und die Request-Verarbeitung durch, managt die Datenübergabe und ist für die View-Ansteuerung und die Steuerung der View-Lebensdauer zuständig.

Hinweis

Ein Redirect von Controller oder Seite zu Controller oder Seite ist problemlos möglich. Siehe auch Navigation.

Empfehlung

Wenn erst durch die Eingabeverarbeitung entschieden werden kann, welche Seite nun folgt, empfiehlt es sich, den Controller auf verschiedene Views verzweigen zu lassen (z.B. wenn intern geprüft wird, ob der Anwender noch nicht als Kunde registriert ist, und dann die entsprechenden Daten abgefragt werden).

Zusätzlich kann ein Controller für die Delegation der Kontrolle über Bilder an Sub-Controller eingesetzt werden. Ein Controller kann die Kontrolle für ein ganzes Bild oder einen Bild-Ausschnitt an einen oder mehrere andere Sub-Controller delegieren. Dadurch kann sich ein komplexer Baum von Controllern aufbauen und es können sich Komponenten bilden (die sowohl aus kaskadierenden Controllern als auch aus dazugehörigen Views bestehen).

Informationen über den Lebenszyklus von Controllern finden Sie unter Lebensdauer.

View

Views sind nur für das Layout zuständig, also für die Visualisierung der Anwendungsdaten. Views sind ganz ähnlich wie Pages, haben jedoch weder Eventhandler noch Auto-Seitenattribute und auch keine eigene URL. Im Gegensatz zu Auto-Seitenattributen sind normale Seitenattribute möglich, die vom Controller gefüllt werden. Controller sollen die Aufrufe der Views steuern und mit einem Model kommunizieren.

Wenn für einen View der Typ der Controller-Klasse bekannt ist (siehe Reiter Eigenschaften des Views), kann der View auch auf die Attribute der Controller-Klasse zugreifen.

Hinweis

Für den Aufruf von Views können Sie den Navigation Modeler verwenden.

Informationen über den Lebenszyklus von Views finden Sie unter Lebensdauer.

Model

Das Model dient der Datenbeschaffung aller notwendigen Anwendungsdaten von der Datenbank. Es repräsentiert die internen Datenstrukturen und entspricht somit der im übrigen BSP-Programmiermodell verwendeten Applikationsklasse. Zentrale Aktionen, die das Model ausführt, sind das Lesen, Modifizieren, Sperren und Sichern von Daten.

Bei der Verwendung von Controllern kann dieser Controller eine Referenz auf eine Klasse anlegen, die als Model dient. Hierfür gibt es die Klasse CL_BSP_MODEL (siehe auch Datenbindung).

MVC in BSP-Applikationen

Diese Grafik wird im zugehörigen Text erklärt

Lesen Sie weiter unter:

Einsatz von MVC für BSP

Klasse CL_BSP_CONTROLLER2

Navigation

Lebensdauer

Aufruf-Möglichkeiten von BSP-Bestandteilen

Aktivitäten

Hinweis

Für Ihre ersten Schritte mit dem MVC Design Pattern steht ein einfaches Tutorial zur Verfügung.

Ein umfangreicheres MVC-Tutorial ist im Rahmen der allgemeinen Bookshop-Tutorials für BSP enthalten: Unser kleiner Online-Buchladen mit Verwendung von MVC und HTMLB.

Beispiel

Ein Beispiel für MVC finden Sie im System in der BSP-Applikation ITMVC2 oder im Paket SBSP_MVC.

Des weiteren sind die folgenden Architekturbeispiele skizziert:

BSP-Applikation mit Controllern und Views

BSP-Applikation mit mehreren Views pro Controller

Kombination der vorigen Beispiele

Aufruf von Controllern anderer Anwendungen

Aufruf mehrerer Controller aus einem View