Components VS single application ?

[Former Member]

Hi All,

Is it advisable to have a web application in one component(18 to 20 views) or have multiple components(which will have 8 to 10 views each) and then integrate them to get the web application in web dynpro for ABAP.

Please give the pros and cons of the 2 approaches.

Thanks & Regards

Raju

Edited by: raju on Jul 25, 2008 4:48 PM

[Former Member · Accepted solution]

Hi Thomas ,

I understand from ur reply is that no. of components should be dependent on functional need and resuability.I have one more question on the same topic.What is the impact on performance in case of single component VS multiple components ?

Thanks & Regards

Gaurav Jain

[thomas_jung · Accepted solution]

>

> Hi Thomas ,
> 
>     I understand from ur reply is that no. of components should be dependent on functional need and resuability.I have one more question on the same topic.What is the impact on performance in case of single component VS multiple components ?
> 
> Thanks & Regards
> Gaurav Jain

It is difficult to quantify because it depends upon the size of the context and how much is actually shared between the components. It also depends upon how you share the data. A shared assistance class might improve runtime access to data by avoiding cross component binding, but generally increases the memory footprint of the overall application. It is a bit of a balancing act.

Personally I would tend to error on the side of impacting performance a small amount yet having a more maintainable and reusable application. The total cost over time of this type of application will be less in general. However this still requires that you might have to use a mixture of approaches to share the data between the components. It might also require a bit more development time upfront. Although I find that once you get your mindset used to mult-component design the impact to initial development time is minimal.

[thomas_jung]

18 to 20 views is quite a lot for one component. There are technical limitations that can be reached. Once you reach the load limit, the workbench simply won't let you add any more views to the component. On the other hand, having too many separate components that are highly interdependent upon one another with lost of shared data can have a runtime performance impact if not structured correctly.

There is no magic rule to say exactly when something should be broken apart. Ideally it should follow a logical approach of the separation of the business logic. For instance if you were building a sales order maintenance application your might logically break down the components between the sales order header and the item data. Perhaps you also have some material related screens that could be used in both the sales order and the delivery screens. Then for reuse you should break those out into their own components as well. Developers should always be on the lookout for good reuse opportunities.

I think if you look at Floorplan Manager to help with the structure of large applications, you will find that building smaller/more numerous components is much easier. The Floorplan Manager helps with the coordination and reuse of these separate components. Of course you can still build multiple UIBBs at the View level as well if that matches what you need.