Implémentation de MVVM dans ABAP

Après mes études, j'ai travaillé comme programmeur C # pendant plusieurs années. J'ai développé des applications WPF en utilisant le modèle de conception MVVM. Puis je suis passé à ABAP. À ma grande surprise, j'ai découvert qu'ABAP est plus un langage procédural qu'un langage orienté objet, bien que SAP travaille dur pour faire progresser le paradigme OO. Le modèle architectural MVC est généralement utilisé pour séparer la logique métier de l'interface graphique. Chaque fois que j'ai essayé d'implémenter le modèle MVC, j'ai rencontré certaines difficultés qui rendent le programme encore plus difficile à maintenir que s'il était écrit dans des procédures. Malgré le fait que l'implémentation MVC soit décrite en détail et avec des exemples dans le livre Design Patterns in ABAP Objects et sur des ressources spécialisées ( sapland.ru , blogs.sap.comet autres), les problèmes de séparation de la logique demeurent. Dans l'implémentation de MVC sur ABAP, le modèle reste une partie indépendante, et la vue et le contrôleur sont étroitement liés. Le couplage fort entre View et Controller rend difficile la maintenance et la mise à l'échelle. Ce qui suit décrit pourquoi cela se produit et comment y remédier.

Modèles MVC et MVVM

Je ne décrirai pas en détail le fonctionnement des modèles MVC et MVVM dans cet article. Je ne donnerai que les principaux points dont nous aurons besoin à l’avenir.



La principale différence entre MVC et MVVM est que dans le premier contrôleur connaît à la fois la vue et le modèle, il est également permis que la vue connaisse le modèle.







Dans le modèle MVVM, la relation entre les couches est plus faible. View ne connaît que ViewModel et ViewModel uniquement Model. View reçoit des données de ViewModel via une référence DataContex.







Le modèle MVVM est conçu pour le développement WPF en C #. Mais son idée peut également être appliquée à ABAP.

Problèmes MVC dans ABAP

Lors de l'implémentation de MVC, en règle générale, les classes Model sont introduites dans la définition globale et les classes View et Controller dans la définition locale. L'utilisation de classes locales est due à la nécessité d'interagir avec les éléments de l'interface graphique. Le fait est que vous ne pouvez pas créer une interface graphique complète sur les classes ABAP. Dans les classes View, vous pouvez utiliser la fonctionnalité de formation de l'interface graphique (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY, etc.), mais cela ne suffit pas. Il est impossible de créer des statuts d'interface graphique, des en-têtes, des écrans, des PBO, des PAI dans la classe.



La vue locale et le contrôleur présentent plusieurs inconvénients:

1. View et Controller ont accès à toutes les variables globales et paramètres de l'écran de sélection.
2. PBO PAI Controller View ( ALV) View ( ALV). View, Controller, View Controller. , .. , Low Coupling.

MVVM ABAP MVA

Voulant tirer parti de MVVM dans ABAP et rendre les couches plus indépendantes, j'ai défini le modèle de développement suivant pour moi-même.







Puisqu'il est impossible d'implémenter MVVM sous sa forme pure sur ABAP, il n'est pas tout à fait correct d'utiliser le ViewModel. Donc, au lieu de ViewModel et Controller, j'utilise Application.



Le principe de séparation logique est similaire au principe MVVM. View transmet les commandes utilisateur à l'application et l'application agit sur le modèle. Il n'y a pas de rétroaction.

Une caractéristique des applications ABAP est que la vue ne peut être mise à jour qu'après une action de l'utilisateur. Même si un processus asynchrone modifie le modèle, il ne pourra pas lancer la mise à jour de la vue. Cette fonctionnalité vous permet d'affaiblir la relation modèle-vue et de déléguer la fonction de mise à jour de la vue à la vue elle-même. En d'autres termes, l'idée elle-même doit décider quand se renouveler et quand non.

Concept MVA

L'implémentation MVA est basée sur une approche orientée objet, où une ou plusieurs classes seront implémentées pour chaque couche de l'architecture. Chacune des couches a un certain nombre de propriétés.



Vue (vue et vue):

• MVA fonctionne avec l'abstraction de vue IView. Toutes les classes View doivent contenir une implémentation IView.
• IView contient des événements qui nécessitent une interaction avec le modèle
• IView contient un contexte - un lien vers les données du modèle qui doit être affiché à l'utilisateur
• La vue peut contenir une logique métier qui ne nécessite pas d'interaction avec le modèle. Par exemple, si vous souhaitez implémenter à partir d'ALV une chute dans la carte contrepartie, alors cette logique s'appliquera à la vue.
• View contient des éléments d'interface graphique dans un groupe de fonctions associé à la classe View.

Application:

• Sert de liaison de la vue et du modèle et constitue le point d'entrée de l'application.
• A des critères de lancement - un ensemble de paramètres qui déterminent avec quels paramètres l'application doit être lancée. Ce sont généralement les paramètres de l'écran de sélection.
• Les critères d'application comprennent le modèle et les critères de présentation. Par exemple, si l'écran de sélection vous oblige à saisir une date de publication et à spécifier un indicateur de sortie de rapport PDF ou ALV, la date de publication fera référence aux critères du modèle et l'indicateur PDF et ALV aux critères de présentation.
• Les critères de lancement sont transmis au concepteur de l'application. L'application crée un modèle et une vue, s'abonne pour afficher les événements et lie le contexte de vue au modèle.

Modèle:

• Contient les attributs publics dont la vue a besoin.
• Contient les critères de calcul du modèle et la méthode d'initialisation.

Implémentation MVA

Considérons la mise en œuvre de MVA en utilisant l'exemple d'un rapport de flux de matières. Le bouton d'actualisation des données sera utilisé comme interaction avec le modèle.



Le diagramme de classes ressemblera à ceci.







Modèle. Le concepteur de modèle prendra les critères de sélection des données en entrée. La classe aura des méthodes d'initialisation et de mise à jour des données, ainsi qu'un attribut avec des données à afficher.















IView. L'interface de vue contient des méthodes pour définir un contexte, afficher une vue, des événements et définir des types de contexte.















IView contient une description de la structure du contexte, et les champs de la structure doivent être une vue de référence







.La vue implémente l'interface IView. De plus, tous les événements utilisateur sont enregistrés par la classe View et déclenchent uniquement les événements qui doivent être traités par l'application. Dans les paramètres d'événement, vous devez transmettre toutes les données nécessaires à partir de la vue (par exemple, les lignes ALV sélectionnées).



Implémentation de la classe View dans la vue ALV







Dans cette implémentation, nous devons définir l'état de l'interface graphique, pour cela, nous allons créer un FM et le connecter à l'instance CL_SALV_TABLE.Il est







important que tous les événements de l'interface utilisateur soient reçus par View (dans ce cas, via ON_USER_COMMAND) et, si nécessaire, View fait RAISE EVENT pour l'application. Cette approche rend la vue et l'application plus indépendantes.



Application.Le concepteur d'application prend les critères d'application (paramètres de l'écran de sélection) comme entrée et instancie le modèle et la vue, s'abonne aux événements de vue et lie le contexte de vue au modèle. Le constructeur est le seul endroit où l'application connaît la vue. L'application contient une méthode RUN qui démarre le programme. Le démarrage d'une application peut être comparé au démarrage d'une transaction avec des paramètres d'écran prédéfinis. Cela lui permet d'être utilisé à partir d'autres programmes sans SUBMIT.







Lancement de l'application. Nous créons maintenant un programme qui lancera l'application.







Voilà, l'application est prête. Vous pouvez regarder le résultat.







Logique métier du côté vue. Les événements qui ne nécessitent pas d'appeler le modèle et le contrôleur peuvent être gérés dans la vue elle-même.



Par exemple, si vous souhaitez implémenter l'ouverture de MM03 en double-cliquant sur MATNR, alors le traitement de cette logique peut être effectué du côté Vue.







Cette logique a été déplacée au niveau de la vue en fonction de considérations: il n'est pas nécessaire d'accéder au modèle pour des données supplémentaires; la logique ne s'applique qu'à ALV, c'est-à-dire s'il y avait une implémentation de View sous la forme d'Excel ou de PDF, cet événement ne pouvait pas être traité.



Références



Modèles de conception dans les objets ABAP

Modèles pour les débutants: MVC vs MVP vs MVVM

Modèles architecturaux dans ABAP: MVC, MVP, MVVM, MVA