Eine BSP Applikation lässt sich wie jede Applikation in die drei Schichten Präsentation, Applikation und Daten trennen. Eine Möglichkeit der Trennung bildet das MVC (Model-View-Controller) Design Pattern, welches im folgenden beschrieben wird.

Komponenten des MVC

Eine MVC Applikation besteht immer aus mindestens einer Instanz der folgenden Komponenten

• Modell (Datenmodell): Beinhaltet alle Daten, stellt auch Business Logik (Datenselektion, Validierung, ORM (objekt-relationales mapping) dar.

• View (Seite): Dient zur Ausgabe der Daten und bildet mit dem Layout die Präsentationsschicht

• Controller: Bildet die Schnittstelle zwischen View und Modell.

Eine BSP Applikation im MVC Design Pattern kann wie folgt aussehen.

Der Controller (Z_CONTROLLER) ist eine Unterklasse von CL_BSP_CONTROLLER2. Der Benutzer ruft zum Starten der BSP Applikation die URL des Controllers (z.B. http://mein_pfad/controller.do) auf. Die Daten werden in einer Klasse Z_MY_BSP_MODEL gehalten. Diese wird von der Klasse CL_BSP_MODEL abgeleitet. Durch diese Vererbung kann die Modell Klasse nur innerhalb von BSP Applikationen wiederverwendet werden. Um eine weitere Verallgemeinerung (Abstraktion) des Modells zu erreichen (z.B. um es in ABAP Report weiter zu verwenden), kann das eigentliche Business Modell in einer separatem Klasse (Z_MY_DATA_MODEL) implementiert werden. Diese Klasse bildet auch die Schnittstelle zur Datenbank.

Eine BSP Applikation besteht aus mindestens einer View (Seite). Diese kann aus mehreren Seitenfragmenten bestehen. Damit die View die Daten des Modells anzeigen kann, wird in den Seitenattributen eine Referenz auf das Datenmodell (in diesem Fall auf Z_MY_BSP_MODEL) hinterlegt. Die Zuweisung der Daten an ein einzelnes Steuerelement (z.B. Edit Feld) erfolgt mittels Datenbindung (siehe unten).

Ablauf der Kommunikation (Request/Reponse)

Der Ablauf eines Requests ist wie folgt.

1. Benutzer ruft die URL des Controllers auf
   1. Es wird die Methode DO_INIT des Controllers durchlaufen. Bei zustandsbehafteten Applikationen (stateful) wird dies nur beim erstmaligen Erstellen der aktuellen Sitzung durchlaufen. Die Methode wird von der Oberklasse CL_BSP_CONTROLLER2 vererbt, muss aber überschrieben werden
      1. Benutzerrechte prüfen
      2. Instanz der BSP Modell Klasse erstellen
      3. Daten initialisieren
   4. Instanz der View erstellen (Methode CREATE_VIEW des Controllers)
   5. Seitenattribute der View (z.B. Referenz der Modell Klasse) setzen (Methode SET_ATTRIBUTE des Controllers)
   2. Es wird die Methode DO_REQUEST des Controllers durchlaufen. Dies geschieht bei jedem Request. Die Methode wird vererbt und muss idR. neu implementiert werden
      1. Es können weitere Initialisierungen vorgenommen werden (z.B. vorherige Fehlermeldungen löschen)
      2. Durch die Methode DISPATH_REQUEST der Controller Klasse wird die Verarbeitung des Requests an eventuell vorhandene Subcontroller delegiert. 
   3. Es wird die anzuzeigende View gesetzt
3. Es wird die Methode DO_HANDLE_EVENT des aktuellen Controllers aufgerufen
   1. Hier findet die eigentliche Verarbeitung der Benutzereingaben statt. Hier erfolgt idR auch der Austausch von Daten zwischen Controller und Datenmodell

Datenbindung

Die Datenbindung zwischen Datenmodell und View erfolgt mittels Data Binding. Zunächst muss die View über eine Referenz auf das Datenmodell verfügen. Dazu wird eine Referenzvariable in den Seitenattributen hinterlegt.

Anschließend kann in der View auf alle öffentlichen Attribute des Modells wie folgt zugegriffen werden:

Es wird hier das Feld BASIC_PARTNO der Struktur DATA des Seitenattribut MODEL eingebunden. Die Modell Klasse verfügt also über ein öffentliches Attribut DATA (Struktur), das Feld BASIC_PARTNO soll hier ausgegeben werden. Alle Eingaben des Benutzers werden ebenfalls in dieses Feld gespeichert (bidirektional).