email article printer friendly more resources

Leverage Third-Party Components
Commercial ASP.NET Web server controls have never been better, and—thanks to the .NET Framework—you can even customize them to fit perfectly with your apps.
by Don Kiely

Technology Toolbox: VB.NET, C#, ASP.NET, XML

ASP.NET provides some interesting development challenges by marrying the object-oriented, component-based technologies in .NET with the Web. On the one hand, ASP.NET brings powerful capabilities to a medium—the Web—that started life as a way to present users with static pages. On the other hand, users expect Web applications to be exactly like desktop applications, even though they run in a browser. Finding products that work well in this desktop-meets-the-Web development environment can be a boon for your ASP.NET projects. I'll give you some pointers about when using third-party Web server control products is appropriate, and how to evaluate them in light of the demanding standards of ASP.NET applications.

I'll start with one bit of advice: If this is your first foray into the world of buying Web server controls, don't expect to find any that perform the same as those for desktop applications. Server controls emit HTML, so you're limited to what you can do in HTML and related technologies, such as client-side scripting.

The software industry has been embroiled in the great buy-vs.-build debate throughout the last decade (see Additional Resources). The debate boils down to an either/or question: Is it better—more time-efficient, cheaper, or more reliable—to buy prepackaged, generic components in which someone else has invested the development and testing effort, spreading the cost over many customers? Or, is it better to develop components in-house, allowing you to customize them for a specific purpose, implement proprietary business rules and trade secrets, and have complete control over the source code?

The debate applies to components ranging from simple UI widgets—data grids, combo boxes—to comprehensive, middle-tier, data-access and business-rules frameworks. Any nontrivial, data-based application needs these UI and database features, and the choice between building your own or buying someone else's is rarely easy or clear. The decision you make becomes a significant part of your app's architectural design.

A third option that's long been available appears rarely in the debates: Base your own custom component on one you buy from someone else. I call this the derive option. The problem with this approach, until recently, was that you had limited ways to accomplish it. It was easier to do if the vendor included source code or at least an API that supported derivation. Otherwise, you were stuck with tools such as subclassing, a potentially powerful but complex technique that's not for the faint of heart or novices.

For the first time, however—at least in Windows, using Microsoft tools—the derive option is feasible and reliable, because it's built into the structure of the .NET Framework and Common Language Runtime (CLR). Everything in .NET is a class that you instantiate as an object; this lets you inherit from that object and implement existing features of the base object selectively while extending it in new ways the original developer didn't imagine.