Implementierung von MVVM in ABAP

Nach meinem Abschluss arbeitete ich mehrere Jahre als C # -Programmierer. Ich habe WPF-Anwendungen unter Verwendung des MVVM-Entwurfsmusters entwickelt. Dann bin ich zu ABAP gewechselt. Zu meiner großen Überraschung stellte ich fest, dass ABAP eher eine prozedurale als eine objektorientierte Sprache ist, obwohl SAP hart daran arbeitet, das OO-Paradigma voranzutreiben. Das MVC-Architekturmuster wird normalerweise verwendet, um die Geschäftslogik von der GUI zu trennen. Jedes Mal, wenn ich versuchte, das MVC-Muster zu implementieren, stieß ich auf bestimmte Schwierigkeiten, die die Wartung des Programms noch schwieriger machen, als wenn es in Prozeduren geschrieben wäre. Trotz der Tatsache, dass die MVC-Implementierung ausführlich und mit Beispielen im Buch Design Patterns in ABAP Objects und auf speziellen Ressourcen ( sapland.ru , blogs.sap.com) beschrieben wirdund andere) bleiben die Probleme mit der Trennung der Logik bestehen. Bei der Implementierung von MVC auf ABAP bleibt das Modell ein unabhängiger Teil, und Ansicht und Controller sind eng miteinander verbunden. Die starke Kopplung zwischen View und Controller erschwert die Wartung und Skalierung. Im Folgenden wird beschrieben, warum dies geschieht und was dagegen zu tun ist.

MVC- und MVVM-Muster

Ich werde in diesem Artikel nicht im Detail beschreiben, wie die MVC- und MVVM-Muster funktionieren. Ich werde nur die wichtigsten Punkte nennen, die wir in Zukunft brauchen werden.



Der Hauptunterschied zwischen MVC und MVVM besteht darin, dass im ersten Controller sowohl die Ansicht als auch das Modell bekannt sind. Es ist auch zulässig, dass die Ansicht über das Modell Bescheid weiß.







Im MVVM-Muster ist die Beziehung zwischen den Schichten schwächer. View kennt nur ViewModel und ViewModel only Model. View empfängt Daten von ViewModel über die DataContex-Referenz.







Das MVVM-Muster wurde für die WPF-Entwicklung in C # entwickelt. Aber seine Idee kann auch auf ABAP angewendet werden.

MVC-Probleme in ABAP

Bei der Implementierung von MVC werden in der Regel die Modellklassen in die globale Definition und die View- und Controller-Klassen in die lokale Definition übernommen. Die Verwendung lokaler Klassen ist auf die Notwendigkeit zurückzuführen, mit GUI-Elementen zu interagieren. Der Punkt ist, dass es unmöglich ist, eine vollwertige GUI für ABAP-Klassen zu erstellen. In den View-Klassen können Sie die Funktionalität zum Erstellen der GUI verwenden (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY usw.), dies reicht jedoch nicht aus. Es ist unmöglich, GUI-Status, Header, Bildschirme, PBO, PAI in der Klasse zu erstellen.



Local View und Controller haben mehrere Nachteile:

1. View und Controller haben Zugriff auf alle globalen Variablen und Parameter des Auswahlbildschirms.
2. PBO PAI Controller View ( ALV) View ( ALV). View, Controller, View Controller. , .. , Low Coupling.

MVVM ABAP MVA

Um MVVM in ABAP zu nutzen und Ebenen unabhängiger zu machen, habe ich das folgende Entwicklungsmuster für mich definiert.







Da es unmöglich ist, MVVM in seiner reinen Form auf ABAP zu implementieren, ist es nicht ganz richtig, das ViewModel zu verwenden. Anstelle von ViewModel und Controller verwende ich also Application.



Das Prinzip der logischen Trennung ähnelt dem MVVM-Prinzip. View übergibt Benutzerbefehle an Application und Application wirkt auf das Modell. Es gibt kein Feedback.

Eine Funktion von ABAP-Anwendungen besteht darin, dass die Ansicht erst nach einer Benutzeraktion aktualisiert werden kann. Selbst wenn ein asynchroner Prozess das Modell ändert, kann die Aktualisierung der Ansicht nicht initiiert werden. Mit dieser Funktion können Sie die Modell-Ansicht-Beziehung schwächen und die Funktion zum Aktualisieren der Ansicht an die Ansicht selbst delegieren. Mit anderen Worten, die Idee selbst muss entscheiden, wann sie sich erneuern soll und wann nicht.

MVA-Konzept

Die MVA-Implementierung basiert auf einem objektorientierten Ansatz, bei dem eine oder mehrere Klassen für jede Schicht der Architektur implementiert werden. Jede der Ebenen hat eine Reihe von Eigenschaften.



Ansicht (Ansicht und IView):

• MVA arbeitet mit der IView-Ansichtsabstraktion. Alle View-Klassen müssen eine IView-Implementierung enthalten.
• IView enthält Ereignisse, die eine Interaktion mit dem Modell erfordern
• IView enthält einen Kontext - einen Link zu den Modelldaten, die dem Benutzer angezeigt werden müssen
• Die Ansicht kann Geschäftslogik enthalten, die keine Interaktion mit dem Modell erfordert. Wenn Sie beispielsweise von ALV einen Sturz in die Kontrahentenkarte implementieren möchten, gilt diese Logik für die Ansicht.
• View enthält GUI-Elemente in einer Gruppe von Funktionen, die der View-Klasse zugeordnet sind.

Anwendung:

• Dient als Bindung der Ansicht und des Modells und ist der Einstiegspunkt in die Anwendung.
• Hat Startkriterien - eine Reihe von Parametern, die bestimmen, mit welchen Parametern die Anwendung gestartet werden soll. Dies sind normalerweise die Parameter des Auswahlbildschirms.
• Bewerbungskriterien bestehen aus Modell- und Präsentationskriterien. Wenn Sie im Auswahlbildschirm beispielsweise ein Buchungsdatum eingeben und ein Ausgabeflag für PDF- oder ALV-Berichte angeben müssen, bezieht sich das Buchungsdatum auf die Modellkriterien und das PDF- und ALV-Flag auf die Präsentationskriterien.
• Die Startkriterien werden an den Anwendungsdesigner übergeben. Die Anwendung erstellt ein Modell und eine Ansicht, abonniert Ansichtsereignisse und bindet den Ansichtskontext an das Modell.

Modell:

• Enthält die öffentlichen Attribute, die die Ansicht benötigt.
• Enthält Modellberechnungskriterien und Initialisierungsmethode.

MVA-Implementierung

Betrachten wir die Implementierung von MVA am Beispiel eines Materialflussberichts. Die Datenaktualisierungsschaltfläche wird als Interaktion mit dem Modell verwendet.



Das Klassendiagramm sieht folgendermaßen aus.







Modell. Der Modelldesigner verwendet Datenauswahlkriterien als Eingabe. Die Klasse verfügt über Methoden zum Initialisieren und Aktualisieren von Daten sowie über ein Attribut mit anzuzeigenden Daten.















Ich sehe. Die Ansichtsoberfläche enthält Methoden zum Festlegen eines Kontexts, zum Anzeigen einer Ansicht, von Ereignissen und zum Definieren von Kontexttypen.















IView enthält eine Beschreibung der Kontextstruktur, und die Strukturfelder müssen Referenzansicht sein







.Die Ansicht implementiert die IView-Schnittstelle. Darüber hinaus werden alle Benutzerereignisse von der View-Klasse registriert und lösen nur die Ereignisse aus, die von der Anwendung verarbeitet werden müssen. In den Ereignisparametern müssen Sie alle benötigten Daten aus der Ansicht übergeben (z. B. die hervorgehobenen ALV-Zeilen).



Implementierung der View-Klasse in der ALV-Ansicht







In dieser Implementierung müssen wir den GUI-Status definieren. Dazu erstellen wir ein FM und verbinden es mit der CL_SALV_TABLE-Instanz.







Es ist wichtig, dass alle UI-Ereignisse von der View empfangen werden (in diesem Fall über ON_USER_COMMAND) und, falls erforderlich, die View RAISE EVENT für die Anwendung erstellt. Dieser Ansatz macht die Ansicht und Anwendung unabhängiger.



Anwendung.Der Anwendungsdesigner verwendet die Anwendungskriterien (Auswahlbildschirmparameter) als Eingabe und instanziiert Modell und Ansicht, abonniert Ansichtsereignisse und bindet den Ansichtskontext an das Modell. Der Konstruktor ist der einzige Ort, an dem die Anwendung über die Ansicht Bescheid weiß. Die Anwendung enthält eine RUN-Methode, mit der das Programm gestartet wird. Das Starten einer Anwendung kann mit dem Starten einer Transaktion mit vordefinierten Bildschirmparametern verglichen werden. Dies ermöglicht die Verwendung aus anderen Programmen ohne SUBMIT.







Anwendung starten. Jetzt erstellen wir ein Programm, mit dem die Anwendung gestartet wird.







Das war's, die Anwendung ist fertig. Sie können das Ergebnis sehen.







Geschäftslogik auf der Ansichtsseite. Ereignisse, bei denen das Modell und der Controller nicht aufgerufen werden müssen, können in der Ansicht selbst behandelt werden.



Wenn Sie beispielsweise das Öffnen von MM03 durch Doppelklicken auf MATNR implementieren möchten, kann die Verarbeitung dieser Logik auf der Ansichtsseite erfolgen.







Diese Logik wird aufgrund von Überlegungen auf die Ansichtsebene verschoben: Das Modell muss nicht für zusätzliche Daten adressiert werden. Die Logik gilt nur für ALV, d. h. Wenn View in Form von Excel oder PDF implementiert wurde, konnte dieses Ereignis nicht verarbeitet werden.



Referenzen



Entwurfsmuster in ABAP-Objekten

Muster für Anfänger: MVC vs MVP vs MVVM

Architekturmuster in ABAP: MVC, MVP, MVVM, MVA