Choosing between a User Control or Web Part for SharePoint

I generally recommend that users don't write Web Parts unless they have to. That confuses a lot of people since most people believe that you have to write Web Parts if you want to do work with SharePoint. This is only partially true.
SharePoint will only display Web Parts on a page. However, there are publicly available shims that allow you to write user controls and have them be displayed as a Web Part. From Share Point’s point of view, the shim is a Web Part. From the point of view of the user control, the shim is simply a control in .NET that is including the user control.
When faced with a decision on how to get content into a SharePoint Web Part on a portal, the question becomes when should you use a user control and when should you use a Web Part. In order to understand this decision, we must first understand the strengths and weaknesses of each approach.

The Power of User Controls

The ability to employ user controls as a part of a SharePoint deployment is very powerful. It takes a technology that developers are already familiar with (or should be familiar with) and is supported by tools and brings it to SharePoint.
AdvantagesThere are three primary advantages to user controls when dealing with SharePoint. They are: familiarity, reusability, and development speed.


· Familiarity
One of the keys to development is managing the degree of change that the team is put through as it transitions from technology to technology. Part of managing that change is minimizing it where possible. This is one of the reasons that user controls are such a good solution for many organizations. User controls are a core ASP.NET construct, they are something that developers are likely already familiar with — or at least aware of.
This familiarity increases the knowledge reuse coming into the project, which keeps morale high, improves productivity, and improves reuse of the experience after the SharePoint project.

· Reusability
Another way user controls are advantageous is that they can be used with other ASP.NET-based solutions. They aren't explicitly tied to SharePoint. If for some reason in the future you decide that SharePoint isn't the right platform for the solutions you're building — or you decide you need to reuse the technology in another non-SharePoint project — you have that capability.

· Development Speed
Direct support by Visual Studio for a visual interface for user controls — as opposed to manually adding in controls through code — is a great advantage in development speed. Having a visual look and feel instantly available makes the process go faster.

Debugging is faster too, as you can construct testing harnesses that fully exercise and instrument the user control. Web Parts are essentially only runable from within SharePoint. This means that you must deal with all of the SharePoint infrastructure while trying to debug.

ASP.NET 2.0 Web Parts and their ability to be used with SharePoint hold promise, but since right now the story of SharePoint and ASP.NET 2.0 is still not perfect, it's more of a future consideration than a potential solution for today.
Maintenance is also easier and faster with User Controls, primarily because they are easier to understand and debug. The net of this is that developing with user controls is substantially faster than developing a Web Part for everything but the most trivial implementations.



Disadvantages
The picture isn't completely rosy or there wouldn't be much discussion about whether to do a user control or a Web Part. There are some places where user controls may not be a great fit.

· Performance
While the overhead of shimming a user control into a SharePoint site may be trivial for most sites, an extremely large site may have to consider the performance impact of having multiple Web Parts actually coming from user controls.
As a practical matter, most people won't be in a situation where the performance difference between user controls and Web Parts will really matter. However, it is still one of the major objections raised by larger organizations to using user controls for their SharePoint development.

· Deployment
The story for deploying user controls is a bit messy. Single compiled DLLs for entire ASP.NET Web sites mean dumping a series of DLLs in to the bin directory or having all of your user controls in one massive project. Although this problem is substantially mitigated with ASP.NET 2.0, it's still an issue for deployments today.
Adding more difficulty is the deployment mechanism created for SharePoint, which doesn't work well with the structure created by the most popular shim — SmartPart. The net result is that deploying user controls can take a different procedure than even deploying your Web Parts. While this is a challenge, it is one that can be relatively easily overcome by some process and tools.


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 Web Part 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