Using an MVC approach you have a model holding all data, a controller manipulating the data and a view displaying the data. This way you can isolate business logic (controller) from business data (model) andÂ display logic (view). Each of the three elements can be developed and tested independently. For example,Â making a change in business logic won’t affect in any way the existing model or views. It allows you toÂ easily maintain or enhance existing applications.
Like most design patterns, an MVC implementation varies slightly from project to project depending on requirements. The programming language also has an influence on MVC. Popular programming languages have one or several MVC variants taking advantage of language “strengths”.
This particular implementation of MVC in custom data explorer has main model and controller classes as singletons initiatedÂ in the abap report. This ensures that through out the abap report life we will only have one model instance and one controller instance. The only other thing the report does is to start the first screen (view). The main abap report file is really just the place where the MVC components get initialized and the first view is displayed. Everything is in either model, controller or view (abap screen) classes.
In short, here’s how it works:
- model instance gets initialized in the report
- controller instance gets initialized in the report. it will also contain a reference to the model instance allowing it to modify the data. controller starts listening with different class methods for each available controller event.
- views draw themselves using data from the model. We’re in the PBO (process before output) flow logic. Each abap screen contains all code (variable, statements, …) to initialize and populate all its elements (inputtext, grids, …) with data from the model instance.
- views dispatch controller events based on user interaction. A user clicks a button, an OK_CODE gets generated, a view reads it and dispatches a controller event based on it. It may attach additional attributes to the event like the content of an input field. Because custom events can only be dispatched from classes, each screen that needs to communicate with the controller will have a local event dispatcher class. The end result is that a view sends a full description of a user action via events to the controller. The controller will receive something like EVENT_TABLE_SEARCH with parameter table_name eq ‘sometable’.
- controller receives an event and acts on it by modifying the model via model own properties. For example, the controller can update the model current selected table by calling something like model->current_table =model->get_table_entry_by_name( ‘table_name’ ). This way, controller contains only the higher business logic, model contains all the methods for handling data at the lower lever. It makes sense because if we modify the model data structure we’ll only have to modify the model methods related to that data structure, the controller remains untouched.
- model is now updated based on user interaction
- PBO (process before output) flow logic gets triggered and the whole process repeats all over again.
This post is part of Custom Data Explorer.