web dyn pro+model view controller concept

[Former Member]

Hi all,

I am new to webdynpro,

Now I am able to use MVC concept, but my doubt is, is there any special reason for using MVC?

I understand the concept of MVC, need why to use it.

Regards,

sarath

[Former Member]

hi,

Model View Controller (MVC) concept to divide a Web Dynpro application into the three levels data retrieval, user interface, and data flow. The implementation parts of a Web Dynpro application can thus be assigned to the Web Dynpro application entities model, view, and controller. These three entities are the central parts of a Web Dynpro application, which you define and program accordingly. Within the terminology chapter, the terms are organized according to their logical relationships, in the same way as they are displayed in the Web Dynpro Explorer.

A second approach is to consider a Web Dynpro application at file system level. All Web Dynpro units consist of one or more Java classes and/or XML files, which are created automatically by the Web Dynpro Generator. Information about the individual files of an application entity is available in the section concerning the creation of the relevant Web Dynpro entities. Information about working with the Web Dynpro entities – for example, on Creating a Project or how to edit one – is available in the Procedures chapter. The information is also available with reference to the individual tools under Web Dynpro Tools. This introduction to the procedural methods of working with the Web Dynpro entities is a preliminary stage to completing the Web Dynpro tutorials, which are also part of the Web Dynpro documentation.

Model View Controller (MVC)

Use

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.

&#9679; 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.

&#9679; Optimized performance due to fewer redirects.

&#9679; Intuitive and easy-to-use interface for application development.

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.

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.

Features

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

&#9679; It provides the data

&#9679; It is responsible for selecting the correct layout

&#9679; It triggers data initialization

&#9679; It executes input processing

&#9679; 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 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 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.

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

If it is not possible to decide which page should follow until input processing, 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, 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 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).

MVC in BSP Applications

For more information, see:

Using MVC for BSP

Class CL_BSP_CONTROLLER2

Navigation

Lifetime

Call Options of BSP Components

Components

Activities

Create Controller

Create View

Call Controller

Call View

Create Error Pages

A simple Tutorial is provided to guide you through your first steps with the MVC design pattern.

Example

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 Application with Controllers and Views

BSP Application with Several Views per Controller

Combination of the Previous Examples

Calling Controllers from Other Applications

Calling Several Controllers from a View

...............................................................

and see the link..........................................................

http://help.sap.com/saphelp_nw2004s/helpdata/en/0f/ab3a3c9ca75402e10000000a114084/frameset.htm

[Former Member]

Hi sarath,

The model view controller paradigm (MVC paradigm) is based on a clear separation of business logic and presentation logic.

· The model represents the business logic and the persistence on the backend.

· The view is the central logical element for the layout and the processing of the presentation logic.

· The controller is responsible for programm control, determining the data flow between the view and the model and handling events.

Thanks and Regards,

Ruthra

[Former Member]

Hi,

Using Web Dynpro enables a clear separation of business logic and display logic. A Web

Dynpro application runs on the front end and has local or remote access to the back end

system via a service. This means that the display logic is contained in the Web Dynpro

application, while the business logic and the persistence of the business objects run in the

back end system. The following options are currently available for connecting Web Dynpro

applications and the back-end system:

An interface generated using adaptive RFC, through which BAPIs of an SAP system

can be called

An interface for calling Web services

A self-generated interface

The source code required for connecting the Web Dynpro application can be generated

from a UML definition of the Web Dynpro interface. A UML definition can be imported

into the Web Dynpro tools as an XML file.

Conversion of the Model-View-Controller

Conversion of the Model-View-Controller Programming Model

Every Web Dynpro application is structured according to the Model View Controller

programming model:

The model forms the interface to the back end system and thus enables the

Web Dynpro application access to data.

The view is responsible for the representation of the data in the browser.

The controller lies between the view and the model. The controller formats

the model data to be displayed in the view, processes the user entries made by the

user, and returns them to the model.

/people/thomas.jung/blog/2006/06/20/web-dynpro-abap-demonstration-videos

http://help.sap.com/saphelp_nw04s/helpdata/en/77/3545415ea6f523e10000000a155106/frameset.htm

Cheers,

vasavi.v