Implementing MVVM in ABAP

After graduation, I worked as a C # programmer for several years. I have been developing WPF applications using the MVVM design pattern. Then I switched to ABAP. Much to my surprise, I discovered that ABAP is more of a procedural language than an object-oriented language, although SAP is working hard to advance the OO paradigm. The MVC architectural pattern is usually used to separate business logic from the GUI. Every time I tried to implement the MVC pattern, I faced certain difficulties that make the program even more difficult to maintain than if it were written in procedures. Despite the fact that the MVC implementation is described in detail and with examples in the book Design Patterns in ABAP Objects and on specialized resources ( sapland.ru , blogs.sap.comand others), the problems with the separation of logic remain. In the implementation of MVC on ABAP, the Model remains an independent part, and the View and Controller are closely related. The strong coupling between View and Controller makes it difficult to maintain and scale. The following describes why this happens and what to do about it.

MVC and MVVM patterns

I will not describe in detail how the MVC and MVVM patterns work in this article. I will give only the main points that we will need in the future.



The main difference between MVC and MVVM is that in the first Controller knows both the View and the Model, it is also allowed that the View will know about the Model.







In the MVVM pattern, the relationship between layers is weaker. View only knows ViewModel and ViewModel only Model. View receives data from ViewModel via DataContex reference.







The MVVM pattern is designed for WPF development in C #. But his idea can be applied to ABAP as well.

MVC problems in ABAP

When implementing MVC, as a rule, the Model classes are brought into the global definition, and the View and Controller classes into the local one. The use of local classes is due to the need to interact with GUI elements. The fact is that you cannot build a full-fledged GUI on ABAP classes. In the View classes, you can use the functionality to generate the GUI (CL_SALV_TABLE, REUSE_ALV_GRID_DISPLAY, etc.), but this is not enough. It is impossible to create GUI statuses, headers, screens, PBO, PAI in the classroom.



Local View and Controller have several disadvantages:

1. View and Controller have access to all global variables and parameters of the selection screen.
2. PBO PAI Controller View ( ALV) View ( ALV). View, Controller, View Controller. , .. , Low Coupling.

MVVM ABAP MVA

Wanting to take advantage of MVVM in ABAP and make layers more independent, I defined the following development pattern for myself.







Since it is impossible to implement MVVM in its pure form on ABAP, it is not entirely correct to use the ViewModel. So instead of ViewModel and Controller I use Application.



The logic separation principle is similar to the MVVM principle. View passes user commands to Application, and Application acts on the model. There is no feedback.

A feature of ABAP applications is that the view can only be updated after user action. Even if some asynchronous process changes the model, it will not be able to initiate the update of the view. This feature allows you to weaken the model-view relationship and delegate the function of updating the view to the view itself. In other words, the idea itself must decide when to renew itself and when not.

MVA concept

The MVA implementation is based on an object-oriented approach, where one or more classes will be implemented for each layer of the architecture. Each of the layers has a number of properties.



View (View and IView):

• MVA works with the IView view abstraction. All View classes must contain an IView implementation.
• IView contains events that require interaction with the model
• IView contains context - a link to the model data that needs to be displayed to the user
• The View can contain business logic that does not require interaction with the model. For example, if you want to implement from ALV a fall into the counterparty card, then this logic will apply to the view.
• View contains GUI elements in a group of functions that is associated with the View class.

Application:

• Serves as a binding of the view and model and is the entry point to the application.
• Has launch criteria - a set of parameters that determine with what parameters the application should be launched. Usually these are the parameters of the selection screen.
• Application criteria consist of model and presentation criteria. For example, if the selection screen requires you to enter a posting date and specify a PDF or ALV report output flag, then the posting date will refer to the model criteria and the PDF and ALV flag to the presentation criteria.
• The launch criteria are passed to the application designer. The application creates a model and a view, subscribes to view events, and binds the view context to the model.

Model:

• Contains the public attributes that the view needs.
• Contains model calculation criteria and initialization method.

MVA implementation

Let's consider the implementation of MVA using the example of a material flow report. The data refresh button will be used as interaction with the model.



The class diagram will look like this.







Model. The model designer will take data selection criteria as input. The class will have methods for initializing and updating data, as well as an attribute with data to display.















IView. The view interface contains methods for setting a context, displaying a view, events, and defining context types.















IView contains a description of the context structure, and the structure fields must be reference







View.The view implements the IView interface. Moreover, all user events are registered by the View class and only raise those events that need to be processed by the application. In the event parameters, you must pass all the data that is needed from the View (for example, the highlighted ALV lines).



Implementation of the View class in the ALV view







In this implementation, we need to define the GUI status, for this we will create an FM and connect it to the CL_SALV_TABLE instance







It is important that all UI events are received by the View (in this case, via ON_USER_COMMAND) and, if necessary, the View makes RAISE EVENT for the Application. This approach makes the View and Application more independent.



Application.The application designer takes the application criteria (selection screen parameters) as input and instantiates Model and View, subscribes to View events, and binds the View context to the Model. The constructor is the only place where the application knows about the View. Application contains a RUN method that starts the program. Starting an application can be compared to starting a transaction with predefined screen parameters. This allows it to be used from other programs without SUBMIT.







Launching Application. Now we are making a program that will launch the application.







That's it, the application is ready. You can watch the result.







Business logic on the View side. Events that do not require calling the model and controller can be handled in the View itself.



For example, if you want to implement opening MM03 by double-clicking on MATNR, then the processing of this logic can be done on the View side.







This logic is moved to the View level based on considerations: the model does not need to be addressed for additional data; the logic only applies to ALV, i.e. if there was an implementation of View in the form of Excel or PDF, then this event could not be processed.



References



Design Patterns in ABAP Objects

Patterns for beginners: MVC vs MVP vs MVVM

Architectural patterns in ABAP: MVC, MVP, MVVM, MVA