Printer Friendly Version

The Performance of Web Parts

For most people, the default answer is to build Web Parts for SharePoint — there are plenty of articles on how to do it, including a few of mine. They have the distinct advantage of being the "stock" answer to the problem. And in some cases they are the best answer for the job.

The primary advantage for creating a Web Part is that everything is available. You can manipulate the tool bar; you can change everything about the way the Web Part behaves. With a user control shim you have limited abilities to reach outside of the container that you're in.

Other than that, the user control's strengths are the Web Part's weaknesses. It's unfamiliar. It's not reusable. It is more difficult to develop and debug. Similarly, the user controls weaknesses are the Web Parts strengths. Web Parts are the best performers. Web Parts have a structured deployment mechanism supported by the core infrastructure.

In most organizations the core advantage for Web Parts turns out to be their performance over user controls. As mentioned above, this is rarely a real concern; rather it is a conditioned response to be concerned with the scalability of the platform. In terms of real performance the difference is fairly minor.

Making the Evaluation

Because the basic understanding of the differences isn't enough, this section dives into some of the other considerations, which emphasizes various strengths or weaknesses of various approaches.

Visual Construction
One of the most popular reasons why I move the bar from creating a user control to creating a Web Part is when the familiarity and development speed benefits of a user control are neutralized. This typically happens when the entire output of the Web Part (or area on the page) is built dynamically. The benefit of the user interface for a user control becomes useless. The familiarity with the concepts fades to the background as the output of the user control becomes more dynamic than normal.

For instance, if you're rendering a set of links or doing replacements on a string to be output, what advantages does a user control really have? The answer is not much, if any. In these cases, it may be better to build a Web Part, which has fewer "moving parts," rather than trying to shoehorn the content into a user control.

Coupling
One of the benefits of a user control is that it can be transported from SharePoint and used in other ASP.NET applications. However, what happens if the user control is tightly coupled to SharePoint. If it has a reference to the Microsoft.SharePoint.dll, then it's no longer reusable outside of SharePoint. So the reusability advantage disappears when you need to make direct use of SharePoint features. In these cases, if the user interface is simple, it may just make sense to be coded as a Web Part. Web Parts are necessarily coupled to SharePoint, therefore the additional coupling to SharePoint is immaterial. When building a replacement Web Part, which controls links on a list page, we made the decision to build a Web Part rather than a user control because the Web Part was deeply integrated into SharePoint. The Web Part applies additional criteria to the visibility of some of the related links — such as 'Alert Me.' Building a user control would not have helped reusability and would have been equally challenging to debug.

Performance
Although I generally believe that performance is too often on developers' minds there are times when performance is an issue to be considered. Generally speaking, the cost of a server and the associated software to run it is trivial in comparison to the cost of developing the solution. With a server being had for less than $5,000 and $5,000 not really even covering the full cost of a developer for a few weeks, it rarely makes sense to focus on performance.

There are, however, obvious places where it makes sense to care about performance. Items that are on every single page are good candidates to be Web Parts. Even with a low overall site volume, a Web Part that is on every page will generate a fair amount of volume, so performance is a valid concern.

For instance, we have a replacement for the Content Editor Web Part. The Web Part's primary function is to allow for relative paths and to enhance caching capabilities. It was done as a Web Part because it exists at least twice on every page — once for the header and again for the footer. This "core" component was pushed towards the side of performance even though it may have been just as easy or easier to develop as a user control.

A Better Mousetrap
The final consideration is that Web Parts lend themselves to a configuration-based design pattern. In other words, you create a generic component to fetch content from a URL rather than creating separate Web Parts for each URL to be fetched. This configuration-based approach is very helpful in reducing code duplication and improving the overall solution.

With SmartPart, there is still a problem with managing how information is pushed down to the user control. The solution is to create your own user control wrapper or to subclass SmartPart to add the ability to push in properties from SharePoint, the query string, and even a form post. This allows you to leverage SharePoint features without creating a coupling between the user controls and SharePoint.

For instance, a user control can expose a public property that accepts the identifier for the current record. The shim has the ID for the current record from the SharePoint properties for the site and notices it available as a public property on the user control. It can push the ID into the public property of the user control. This allows the user control to remain free of SharePoint coupling and still leverage a configuration based approach

Conclusion

Most of the time the assumption is that you have to write a SharePoint WebPart to get functionality in SharePoint is wrong. More frequently, it is appropriate to develop ASP.NET user controls and leverage them in SharePoint through shim technologies like SmartPart.

Go to page: 1 2

Printer Friendly Version