Number, Size, and Genericness of Components
The Ideal Design of a Component
Communication between components requires work and makes the performance of the application suffer. Despite this, you should not make each component too big. You need to balance these requirements, while making sure that each component is a self-contained logical unit. You must always prevent different development groups from working on the same component. We have put together the following guideline for the optimum number of views in a component:
Whenever possible, restrict your components to a maximum of 15 views .
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 extend 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.
View or Component
A component is a reusable unit in the Web Dynpro Framework. A view can be displayed only once within a component; a component, however, can be instantiated multiple times. This means that, if you want a view to appear more than once in a window, you must make it a separate component and reuse it multiple times in a different component.
A component is a visual unit. For this reason, we recommend that you embed only one interface view on the window of the "using" component for each declared component usage.
Model Components
We no longer recommend that you create 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 (see Context ).
The Genericness of Web Dynpro Components
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.