ASP.Net excessive use of User Controls

Architectureasp.netperformancetraceuser-controls

I'm investigating an asp.net web application that extensively uses User Controls on each page. Most pages contain around 10-20 user controls. The User controls seem to be the visual representation of the business objects (if that makes sense), although at a finer granularity such as each tab of a tab control having its contents in a user control. The project itself has over 200 user controls (ascx files).

The performance of the application is very poor (and the reason I'm investigating). Each event (such as a click or dropdown selection etc) requires about 5 seconds for the page to load (10 seconds whilst in visual studio). The application has no use of Ajax.

Tracing is painful as the aspx pages themselves have no code in the code-behind as the user controls look after all of this, so tracing a single page requires trace statements in all the user controls that are on that page.

I actually think that having each user control look after its business code and being re-usable is a smart idea, but is an excessive use of user controls going to incur a performance hit? Does this seem like the structure of an asp.net application that was written by someone with a strong WinForms background?

EDIT
thought I should add that i'm not questioning the use of user controls (or even the amount) but simply whether having so many on a page that all accomplish things (each user control connects to the database for example) will generally cause performance problems…For example, if just one user control postsback to do something, what about the processing of all the others, some are visible and some aren't…@David McEwing mentioned that he had 40 optimised user controls performing etc, but if the developer was WinForms based or "not familiar with asp.net", then how are they going to make sure each one is optimised…

EDIT2
After getting a sql statement trace, the same calls for data are being executed 5-6 times per page call for each event as the different user controls require data that is not stored commonly e.g. each user control in the tab (mentioned above) makes the same call to populate an object from the database…I'm really not here to accuse user controls of being the problem (should i delete the question?) as clearly the problem is NOT user controls but with the use of them in this particular case…which I believe is excessive!

Best Answer

10-20 (or even hundreds) User Controls alone is beyond trivial. The presence of the controls themselves, and the idea of encapsulation, is definitely not the source of your problems.

It's impossible to say precisely what the problem is without actually profiling the application of course, but based on my experience I can say this:

What is more likely is the specific implementation of the business logic inside each user control is poor. With postbacks taking as long as you describe, each control probably looks back to your DAL for its own data on each request. This can be mitigated by two things:

Make sure user controls cache all their data on first load and never re-load it unless explicitly instructed to (usually by an event from a lower-level service)
Ensure the controls all use a set of common services which can reuse data. E.g. if two controls need access to the customers list, and they are executing in the context of the same request session, that should only require one customer list lookup.

Related Solutions

Javascript – Which “href” value should I use for JavaScript links, “#” or “javascript:void(0)”

I use javascript:void(0).

Three reasons. Encouraging the use of # amongst a team of developers inevitably leads to some using the return value of the function called like this:

function doSomething() {
    //Some code
    return false;
}

But then they forget to use return doSomething() in the onclick and just use doSomething().

A second reason for avoiding # is that the final return false; will not execute if the called function throws an error. Hence the developers have to also remember to handle any error appropriately in the called function.

A third reason is that there are cases where the onclick event property is assigned dynamically. I prefer to be able to call a function or assign it dynamically without having to code the function specifically for one method of attachment or another. Hence my onclick (or on anything) in HTML markup look like this:

onclick="someFunc.call(this)"

onclick="someFunc.apply(this, arguments)"

Using javascript:void(0) avoids all of the above headaches, and I haven't found any examples of a downside.

So if you're a lone developer then you can clearly make your own choice, but if you work as a team you have to either state:

Use href="#", make sure onclick always contains return false; at the end, that any called function does not throw an error and if you attach a function dynamically to the onclick property make sure that as well as not throwing an error it returns false.

Use href="javascript:void(0)"

The second is clearly much easier to communicate.

R – ASP.NET Passing properties to dynamically generated user controls

repeater control bound to the same data source as the listbox?

Best Answer

Related Solutions

Javascript – Which “href” value should I use for JavaScript links, “#” or “javascript:void(0)”

R – ASP.NET Passing properties to dynamically generated user controls

Related Topic