Introduction

The Model View Controller design pattern is not invented by SAP. It is a design pattern to separate the business logic from the view. For example the view could be a Dynpro, WDA or BSP. To connect the business logic to a view we have the controller. This makes it possible to use the same business logic for different views.

There are several solutions build in ABAP to use the MVC design pattern for example:
• The BUS Screen framework
• SAPMVC
• Classes created for the ALV - noticed by Thomas Jung

These are really neat solutions, but I think they have overhead, are too much ABAP minded and the model isn’t flexible enough. Therefore I created my implementation of the MVC design pattern in ABAP for practical use. I understand that we can’t really compare it with the BUS Screen framework, because this is a complete framework as the name describes.

Content of the blogs

There will be two parts to explain the complete concept.
In this part I will present the concept of the view-controller with a screen manager.
In the next part the model-controller with a model manager will be presented.

Requirements of the concept

• Separation of business logic and output
• Reuse of screens
• Reuse the Module code of the PBO and PAI
• Compatible with Subscreens and Controls (Tabstrip, Tableview, etc.)
• Keep it simple!

Flow of an application

1. Start of the application
2. Call a screen
3. Request for data (the model)
4. Setup the screen
5. Handle actions of the screen or model events

Repeat point 2 till 5.

The concept

At runtime every screen is bound to exactly one controller. The controller is responsible for point 2 till 5 of the application flow. You can bind a controller to screen with the screen manager.
The image below shows the simple view of the concept.

The controller must be a local class that is inherited from a global class that implements the interface ZIF_SCREEN_CNTRL. The controller class must be created in the same program as the screen.
The image below shows the full view of the concept.

How to call a screen

zcl_screen_manager=>call_screen( EXPORTING iv_program = sy-repid iv_screen = '9000' iv_controller = 'LCL_SCR_CNTRL_9000' ).

Or

DATA lx_screen_manager TYPE REF TO zcx_screen_manager. DATA lv_error_message TYPE string. TRY. zcl_screen_manager=>call_screen( EXPORTING iv_program = sy-repid iv_screen = '9000' iv_controller = 'LCL_SCR_CNTRL_9000' ). CATCH zcx_screen_manager INTO lx_screen_manager. lv_error_message = lx_screen_manager->get_text( ). MESSAGE lv_error_message TYPE 'E'. ENDTRY.

Template for the local controller class

CLASS lcl_scr_cntrl_9000 DEFINITION INHERITING FROM zcl_screen_cntrl. PUBLIC SECTION. METHODS call_screen REDEFINITION. METHODS set_data REDEFINITION. METHODS set_display REDEFINITION. METHODS handle_action REDEFINITION. ENDCLASS. CLASS lcl_scr_cntrl_9000 IMPLEMENTATION. METHOD call_screen. CALL SCREEN gv_screen. ENDMETHOD. METHOD set_data. "Get data from model ENDMETHOD. METHOD set_display. "Set screen ENDMETHOD. METHOD handle_action. CASE gv_action. WHEN ''. WHEN 'EXIT'. LEAVE TO SCREEN 0. WHEN OTHERS. "When you don't want to refresh the screen gv_refresh = abap_false. ENDCASE. ENDMETHOD. ENDCLASS.

The PBO and the PAI

The code for the PBO and the PAI is always the same.

* PBO MODULE pbo OUTPUT. CLEAR ok_code. zcl_screen_manager=>set_screen( EXPORTING iv_program = sy-repid iv_screen = sy-dynnr ). ENDMODULE. * PAI MODULE pai INPUT. zcl_screen_manager=>handle_action( EXPORTING iv_program = sy-repid iv_screen = sy-dynnr iv_action = ok_code ). ENDMODULE.

When we need to have a custom module for example a value help, then we create a new module.

* Custom PAI MODULE pai_[NAME] INPUT. zcl_screen_manager=>handle_action( EXPORTING iv_program = sy-repid iv_screen = sy-dynnr iv_action = [ACTION] ). ENDMODULE.

Subscreens

The subscreen controller is set in the method SET_DISPLAY of the local controller

zcl_screen_manager=>set_controller( EXPORTING iv_program = sy-repid "Or other program iv_screen = '9001' iv_controller = 'LCL_SCR_CNTRL_9001' ).

Setup

You can add the classes for the MVC concept with the program SAPLINK
You need the plugin for a CLASS and INTERFACE.

The link to the nugget is: RV_ABAP_MVC

The next part

What if the business logic is in a function group or in a business object. Or what if the business logic is SAP standard code. How can you attach your local view controller to handle events from that kind of model.
In the next part I will present the model-controller with a model manager. For that we will extend the controller class to handle a model event and I will explain how to use the same model instance in different views.