Encapsulating Classical User Interfaces
The separation of concerns is one of the basic rules of these ABAP programming guidelines. This separation, which refers to a strict division of ABAP code into parts for presentation services, application services, and persistency services, is also technically possible for classical dynpro-based UI technologies. The MVC approach is not directly supported, but SoC can also be achieved though the consistent use of the available encapsulation technologies.
However, SoC was rarely implemented in classical dialog programming. Here, presentation logic, application logic, and persistency logic were often combined in a monolithic module pool.
Encapsulate classical dynpros and selection screens
Only create classical dynpros and selection screens in the presentation layer programs specifically provided for this purpose. You can use function groups as the program type.
When using classical UI technologies, you need to separate the display logic from the application logic for the following reasons:
- Reuse individual components
- Automated program logic tests, irrespective of the UI
- Change the UI technology
In addition, the communication between classical dynpros/selection screens and ABAP programs is implemented using global variables. This poses conceptual problems and cannot be combined with a modern, object-oriented approach for application programs.
Since class pools do not support classical dynpros and selection screens, you can only use function groups for encapsulation. In this role, a function group must be considered a global class. Here, the data of the global declaration part assumes the role of the private attributes, and the function modules assume the role of the public methods. The relevant procedure is demonstrated in DEMO_CR_CAR_RENTAL_SCREENS of package SABAP_DEMOS_CAR_RENTAL_DYNPRO. It applies to selection screens.
Besides UI elements, these function groups can only contain display logic in the form of local classes. The application logic communicates with the display logic using the function modules of this function group. You can still call the first dynpro of a dynpro sequence using a transaction code. This method is used in cases where the user starts the application.
The guidelines described in this book are also valid in function groups. It is especially important that the dialog modules (PBO and PAI), which are called by the dynpro, or the event blocks for selection screen processing do not contain any program logic. Instead they should directly delegate the processing to the relevant methods of the local classes. The same applies to the function modules that act as the external interface. In addition, you must restrict the scope of the function group global data to the minimum scope required for communicating with dynpros.
Following the above rule means you cannot use standard selection screens. Therefore, it is necessary to make an exception to this rule for executable programs that are executed during background processing. This is because the required parameter interface must be a standard selection screen defined directly in the program. An encapsulation in a function group is not possible here. However, in this case, the events of selection screen processing should only call one appropriate method of a local class within the executable program.
A classic dialog program - usually a single module pool - processes all the facets of an application.
The following source text shows a part of a function group DEMO_CR_CAR_RENTAL_SCREENS with expanded
include programs. This function group encapsulates the dynpro and selection screen for transaction
DEMO_CR_CAR_RENTAL, following the above rule. The connection to the application layer is established
exclusively using the
if_demo_cr_car_rentl_service interface, which is also used in the Web Dynpro application of this transaction.
* Top Include
SELECTION-SCREEN BEGIN OF SCREEN 200 TITLE text-ccr.
PARAMETERS g_name TYPE demo_cr_customer_name.
SELECTION-SCREEN END OF SCREEN 200.
CONTROLS: customers TYPE TABLEVIEW USING SCREEN 0100,
reservations TYPE TABLEVIEW USING SCREEN 0100.
DATA g_ok_code TYPE sy-ucomm.
DATA: g_customers TYPE TABLE OF demo_cr_scustomer_cntrl,
g_customer LIKE LINE OF g_customers.
DATA: g_reservations TYPE TABLE OF demo_cr_sreservation_cntrl,
g_reservation LIKE LINE OF g_reservations.
* Local Class Declarations
TYPE REF TO if_demo_cr_car_rentl_service.
* Function Module
CALL SCREEN 100.
* PBO Modules
MODULE status_0100 OUTPUT.
MODULE customers_change_tc_attr OUTPUT.
* PAI Modules
MODULE cancel INPUT.
MODULE user_command_0100 INPUT.
MODULE customers_mark INPUT.
* Local Class Implementations
100 is called in a function module but can also be linked to a transaction
code. In the classical PBO and PAI modules, methods of local classes are called. However the implementation
of these methods is not shown here. There is a class for general screen handling and a class for each table control. The application layer is accessed using the specified interface for implementations of the class.