Model View Controller (MVC)

SAP Web Application Server 6.20 has implemented the Model View Controller (MVC) design pattern. This is widely used in the user interface programming field and which has established itself as an enhancement of the previous BSP implementation model. Its controller-based approach 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 benefits:

• Simplified structuring of BSP applications, since the view is cleanly separated from the controller and the model. This facilitates modification of BSP applications and makes them considerably easier to maintain.

• 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. Moreover, you remain in the same work process, which can be beneficial when creating objects and memory space. Calling using the <bsp:call> element is more variable than insertion using the INCLUDE directives, since it is triggered at runtime.

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

• Optimized performance due to fewer redirects.

• Intuitive and easy-to-use interface for application development.

  Note

  Previous BSP applications, which did not have MVC, can still run without any changes being made. MVC does, however, have various advantages with more complex applications. See Using MVC for BSP.

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.

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:

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

Controller

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 executes the following tasks:

• It provides the data

• It is responsible for selecting the correct layout

• It triggers data intialization

• 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.

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 therefore takes on all the tasks that were performed by the Event Handlers in the previous BSP program model. It performs the request processing, manages the data transfer and is responsible for controlling the view and the view lifecycle.

A controller can also be used to delegate control over screens to the subcontroller. A controller can delegate the control for a whole screen or a screen section to one or more different subcontrollers. This makes it possible to depict a complex tree structure of controllers, including Components (consisting 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, auto-page attributes, or their own URL. Unlike auto-page attributes, normal page attributes can be used that 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.

Model

The model is used to obtain all necessary application data from the database. It represents the internal data structures and corresponds to the 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).

• Creating Controllers

• Creating Views

• Calling Controllers

• Calling Views

• Creating Error Pages

You can find an example of MVC in the system in BSP application BSP_MODEL.

Basic information is also provided about the following Architecture Examples:

• BSP Applications with Controllers and Views

• BSP Application with Several Views per Controller

• Combination of the Previous Examples

• Calling Controllers of Other Applications

• Calling Several Controllers from a View ‎