Back Draft
Staying Familiar
Use industry-standard components and tools to reduce development and maintenance time.
By Jonathan Goodyear
Here's a common scenario: You're working on a project, but the functionality you want doesn't come with the .NET Framework out of the box. Of course, you could build it yourself. A strong argument can be made, however, for using a third-party component instead of custom-rolled code.
For example, what should you do if you need to add charting capabilities to your ASP.NET Web application? You could build your own charting library, as the .NET Framework has a relatively powerful GDI+ implementation baked right in. Even so, you might want to think about buying a third-party charting component. Why? For tasks that are as standardized as charting, you'll most likely be better off choosing a solution that future developers who come onto the project are familiar with. It is pretty inefficient to explain your custom charting engine to every new developer you hire, let alone document the component (which can be an ordeal in itself). Lastly, third parties who dedicate themselves to solving a particular problem usually have more time invested in finding the best solution possible.
Speaking of using industry-standard components, one of the first tasks in most .NET data-access projects is to build some wrapper classes for ADO.NET. For all the power ADO.NET has, it is awfully verbose to implement. The problem with building your own ADO.NET wrapper classes is everyone does it differently, with varying degrees of success at abstracting the details of ADO.NET from everyday development tasks. What if I told you Microsoft already has done the work for you and built a set of standard wrapper classes for ADO.NET? Well, it has, as part of its "Patterns and Practices" initiative (http://msdn.microsoft.com/practices/).
Patterns and Practices is Microsoft's solution to the growing problem of standardizing the best .NET development patterns. Although the entire initiative is fairly large in scope, I'd like to focus on the section named Microsoft Application Blocks for .NET. Application Blocks are free best practices solutions to common development problems. At press time, Microsoft has built two Application Blocks. The first (as I alluded to previously) is named Data Access Application Blocks for .NET (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daab-rm.asp). I have been using Data Application Blocks for several weeks, and although they don't quite abstract the user as far away from the ADO.NET plumbing as I'd like, they do handle a lot of headaches such as dealing with stored-procedure parameters, handling transactions, and (most importantly) closing connections and destroying objects.
The second Application Block Microsoft has built is the Exception Management Application Block for .NET. This Application Block consolidates most of the plumbing code necessary to handle exceptions in an efficient and isolated manner, as well as log and communicate these exceptions properly with fewer lines of code intertwined in your business logic.
I encourage you to consider using the Microsoft Application Blocks for .NET in your projects vs. rolling your own code. At the most recent regional directors meeting at Tech-Ed in Dallas, Texas, I was told Microsoft has gone through an extremely rigorous testing process to ensure the Application Blocks' stability. Microsoft is highly committed to the Application Blocks, as well as the entire Patterns and Practices initiative. So eventually, most developers who come to work for your organization will be familiar with how they work already (as opposed to you having to explain your custom logic and processes to them). I think that's a good thing for all those concerned.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, Fla. He's a Microsoft Certified Solution Developer (MCSD) and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.
