Choosing Between a User Control or Web Part for SharePoint
Robert Bogue
1/20/2006
Go to page: 1 2
Printer Friendly Version
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 SharePoint'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.
Advantages
There 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.
Go to page: 1 2
Printer Friendly Version
Events
[
Home | Discussion Forum | How Do I... |
Lotus Notes Intranets |
Microsoft SharePoint |
Products |
Shopping
]
