Dos and Don’ts: Webdynpro Components.

[manigandan_d2]

v Do not write your entire application source code in Web Dynpro components.

v Write your application source code in ABAP OO classes. For example, use the assistance class.

v As a rule, every ABAP class can serve as an assistance class. However, the services integrated in the Web Dynpro framework are available only if the assistance class is derived from the class CL_WD_COMPONENT_ASSISTANCE. Note that the assistance class must not have any required parameters in the constructor.

v SAP no longer recommends creating special model components, since they do not offer any benefits over model classes. One alternative is to use a shared assistance class to provide a model.

v Do not create single view in Web Dynpro component try to split it into many, so it can be reused.

v Always prevent different development groups from working on the same component.

v In a Web Dynpro component, group together as many views that belong to one application part as possible. If, however, the ABAP workload is too large, split the component up.

v Whenever possible, restrict your components to a maximum of 15 views.

v Make sure that the number of controllers used by each controller does not exceed 8. Remember, at runtime you create a load from your components. The size of this load depends to a great extent on the number of views, UI elements, controllers, controller usages, and the size of the context nodes. If this load is too big, the system produces a warning telling you that limited resources are available at runtime for the WDA application. Performance drops.

v Generic components are more difficult to maintain than explicitly programmed components, which is why we recommend that you make all your components only as generic as they absolutely need to be. This requirement needs to be balanced with the demands of distributed application development groups. These groups need to provide generic components that are then, for example, given a uniform layout at a later time or by a different group. As a guideline, we recommend that you make your applications generic to the extent that, when the resulting component is configured, around 80% of all applications are covered. Do not try to make your component more generic just to cover the remaining 20% of the possibilities.

v Delete all Web Dynpro component instances as soon as they are no longer needed. To do that, use IF_WD_COMPONENT_USAGE=>DELETE_COMPONENT.

v Use dynamic navigation or dynamic component usages only if it is absolutely necessary.

v Set the lifetime of a view to when visible, if the view is displayed only once in an application.

v As far as possible always set the lifetime to when visible. Note: Although memory consumption is reduced by the lifespan of when visible, when visible can affect performance since in this case the view has to be initialized every time it is displayed.

Regards,

Mani