Model View Controller (MVC) (SAP Library - Model View Controller (MVC))

Model View Controller (MVC)

Use

SAP Web Application Server 6.20 has implemented the Model View Controller (MVC) design pattern, which is widely used in the user interface programming field and which has proved its worth, as an extension of the previous BSP implementation model. Its controller-based use ensures an even clearer distinction between application logic and presentation logic in BSP applications. You can structure graphical user interfaces clearly and organize them in logical units, even with complex applications.

Using the MVC design pattern has the following advantages:

· Structuring BSP applications is simplified, since the view is cleanly separated from the controller and the model. This not only facilitates changing BSP applications, but also considerably improves their maintenance.

· You have the option of generating program-driven layout. The HTML/XML output is therefore created by program code instead of a page with scripting.

· Navigation using the <bsp:goto> element and call using the <bsp:call> element. The advantage of using <bsp:goto> navigation over redirect is that there is no additional network traffic. Furthermore, you remain in the same work process, which can have advantages for creating objects and memory space. The call using <bsp:call> element is more variable than adding them using INCLUDEdirective, since it is triggered at runtime.

With the call option using <bsp:call>, you can also distribute the user interface into components.

· Optimized performance due to fewer redirects.

· Intuitive and east-to-use interface for application development.

Note

Previous BSP applications, that is, BSP applications without MVC, can still be executed without requiring any changes. MVC does, however, have various advantages with more complex applications. See Using MVC for BSP.

Integration

The MVC design pattern is integrated in the BSP programming model and the Web Application Builder of the ABAP development environment (Transaction SE80) from SAP Web Application Server 6.20.

Functions

A BSP application can consist of one or more controllers and Business Server Pages, as well as known elements such application classes, MIME objects and themes. A BSP can have different characteristics; it is either a page with flow logic (as before), or a view or a page fragment:

This graphic is explained in the accompanying text

Within a BSP application, there can be several controllers, several views and several pages with flow logic.

Controllers

A controller is the instance of a central controller class. In the BSP-MVC environment, each controller is directly or indirectly derived from the same base class CL_BSP_CONTROLLER2, where the central method is DO_REQUEST.

There is a URL for every controller that can be addressed externally, such as using a browser. A controller can therefore be used as the initial point of entry to a BSP application. The mapping of the URL to the controller class is determined in the BSP application.

A controller is the controlling instance in the MVC design pattern, where it also acts as the controlling mechanism. It carries out the following tasks:

· It provides the data

· It is responsible for selecting the correct layout

· It triggers data initialization

· It executes input processing

· It creates and calls a view instance

Layout selection

A controller will usually call a view instance for creating the HTML / XML output. The controller can call a view that is created using a factory method. The theme or the browser variant, for example, can be used here as the selection criteria. If a controller passes the control to a view, it can – and should – set attributes to the view. These attributes may just be data, or a reference to one (or, in extreme cases, several) model(s). A reference to the controller is automatically transferred.

Caution

A controller has access only to views in its own application.
A controller can, however, delegate processing to another controller, and this controller can be located in a different application.

A controller should not work with too many views, since all of these requests are processed centrally. On the other hand, the controller should jump to all views that have the same or very similar input processing.

Data provision

Although a controller does not have any pre-defined attributes, they can be set and read using generic methods. However, a controller should provide a method init_attributes, which is responsible for filling the attributes. There is a service method that facilitates filling the attributes.

Event handling

The controller also takes care of event handling. It takes on all of the tasks that were executed in the previous BSP programming model by the event handlers: It carries out initialization and request processing, manages data transfer and is responsible for managing views and controlling a view’s lifetime.

Note

Redirects from the controller or page to the controller or page can be easily implemented. See also Navigation

Recommendation

If it cannot be decided until input processing which page should follow, we recommend that you let the controller branch to different views (for example, if it is checked internally whether the user has registered as a customer, and the corresponding data is then queried).

A controller can also be used to delegate control over screens to the sub-controller. A controller can delegate the control for a whole screen or a screen section to one or more different sub-controllers. This can result in a complex tree structure of controllers and components can be formed (that consist of both cascading controllers as well as their corresponding views).

You can find information about the life cycle of controllers in Lifetime.

View

Views are only responsible for the layout; they visualize the application data. Views are very much like pages, although they do not have event handlers nor auto-page attributes, nor their own URL. Unlike auto-page attributes, normal page attributes can be used, which are then filled by the controller. Controllers should control calling views and communicate with a model.

If the type of controller class is known for a view (see the Properties tab for the view), the view can also access the attributes of the controller class.

You can find information about the life cycle of views in Lifetime.

Models

The model is used to obtain all necessary application data from the database. It represents the internal data structures and corresponds to the Structure link application class used in the remaining BSP programming model. The model is responsible for carrying out the central actions of reading, modifying, blocking and saving data.

When used with controllers, this controller can create a reference to a class that is used as a model. Class CL_BSP_MODEL is available for this (see also Data Connection).