Preaching What You Should Practice

The Enterprise Library lends a helping hand to those whose minds are becoming discombobulated by swirling patterns and coding practices.

• By Mike Gunderloy
• 05/05/2005

As my programming career continues, I am reminded more and more often of Plato’s words. It seems that every year I learn new things, without being allowed to forget the old ones. The end result is that I know less and less about more and more. Ask me general architectural questions and I can often dredge up the answer quickly; ask me about the syntax of a particular method and I go scurrying for the help files. Lately, even the architectural patterns are getting harder to grasp. I don’t think I’m getting (much) dumber. There’s just an overwhelming amount of code out there to master if you want to be a good developer.

EntLib to the Rescue
For the .NET world, at least, help is at hand. The Enterprise Library (which you can download by clicking here) is a collection of best practices code from the Patterns & Practices group at Microsoft. More precisely, it’s an integrated version of the .NET Application Blocks, which were released piecemeal over the last couple of years. The new version of Enterprise Library (EntLib to its friends) contains these Application Blocks:

• Caching, to handle local caching
• Configuration, to read and write configuration information
• Data Access, to use databases in a standard manner
• Cryptography, which handles encryption and hashing
• Exception Handling, which standardizes handling errors
• Logging and Instrumentation, for tracking what’s going on
• Security, to deal with a variety of security issues

In addition to the compiled Application Blocks, EntLib includes full source code with unit tests, an extensive help file, QuickStart applications to demonstrate the use of the blocks, and a Configuration Console that simplifies the task of setting up EntLib for your own application. You can choose which pieces to include; you’re not committed to dragging around a bunch of unnecessary code.

Access Your Data
Take the common task of pulling data out of a database. If you’ve ever used the .NET Framework for this, you know that there are a ton of alternatives in the System.Data namespace, as well as associated namespaces to handle the different database types (such as SQL Server or Oracle). It’s easy to get confused about the most efficient way to pull back a value from a database, or to forget to properly shut down some object that you’ve used in your code.

EntLib addresses these problems in a couple of ways. First, it provides a portable layer over three major databases (SQL Server, Oracle, and DB2). Second, it distills the array of database methods into some simple patterns that cover 90 percent or more of the data access tasks in a typical application.Take the case of retrieving a value from the database. With the Data Access Application Block, the code is something like this:

Database db = DatabaseFactory.CreateDatabase();
int productID = 4;
string sqlCommand = "GetProductName";
DBCommandWrapper dbCommandWrapper =
   db.GetStoredProcCommandWrapper(sqlCommand, productID);
string productName = (string)db.ExecuteScalar(dbCommandWrapper);

That’s it! You’re done. The code is independent of the database type and even the database name: those are handled in the application’s configuration file (which can be manipulated with the Configuration Console).

Yummy Provider Goodness
One of the nice things about EntLib is its pervasive use of providers to handle low-level functionality. A provider is a component that plugs into a particular interface that an Application Block needs to do its work. For example, the Data Access Application Block lets you use SQL Server, Oracle, or DB2 providers to handle the actual task of talking to the database. Other places where the provider pattern occurs include the Caching Application Block (choose between Isolated Storage or a database for caching), the Exception Handling Application Block (wrap or replace exceptions, or send them off to be logged), and the Logging and Instrumentation Application Block (log to database, e-mail, flat file, event log, or MSMQ).

In addition to providing portability and flexibility, the providers add lots of extensibility to EntLib. All of the interfaces that they use are well-documented (indeed, the documentation overall is excellent), and if you want to add another provider it’s easy to use this documentation, together with the source code for an existing provider, to do so. So it you need, say, a MySQL database implementation on the bottom end, it shouldn’t be too hard to add.

The Tip of the Iceberg
Though it’s a very visible -- and useful! -- offering, EntLib is hardly the only thing that the Patterns & Practices group has to offer the developer. If you’re not already familiar with that group's Web site (http://www.microsoft.com/resources/practices/default.mspx), you should be. They sponsor conferences, host Webinars, and otherwise try to get the word out about best practices (not just in .NET, but in a bunch of other areas related to Microsoft software). Among their most useful products are a series of book-length guides that you can use to help you grasp good software architecture. A few of the topics covered:

• .NET and J2EE integration
• Building secure ASP.NET applications
• Deploying .NET applications
• Designing and using a data tier
• Improving .NET performance and scalability
• The “Smart Client” architecture
• Unix application migration

You’d expect to pay hundreds of dollars to get the same information from commercial publishers, or thousands upon thousands to learn it in seminars. Instead, you can pay only the cost of your Internet connection to download it from Patterns & Practices. It’s a great deal.

Final Thoughts and Cautions
You can use the Enterprise Library in many ways. If you just want some well-tested components to handle common tasks, you can drop it into your application as is. If you’re focused on a particular problem area, but you have unusual requirements, you can start with the existing Application Blocks and extend them through their provider interfaces or other means. If you’re looking to understand good architecture for enterprise-ready .NET applications, take a look at the QuickStarts and read through the documentation carefully. If you want to see how unit testing can be applied to a substantial project, take a look at the included unit tests.

My only caveat here is that you should remember that not every application is an enterprise application. If you just need to retrieve a single value from a database at application startup, and never touch the database again, you probably don’t need to bring along all the baggage of the Data Access Application Block, for example. Be smart about whether you want to actually use this code layer. But even if it proves to be too much for your own application, you should still be able to learn from the practices here. And that’s the main point.

Are you happy to have Microsoft pushing out an application framework for us all to use? Or should they concentrate on building the parts that other people can’t? You can get hold of me at [email protected]. I’ll use the most interesting comments in a future column.