Review: patterns & practices Enterprise Library

patterns & practices Enterprise Library
Redmond, Washington

Late last week Microsoft released the Enterprise Library, 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. This is a great replacement for the tedious and error-prone alternative of editing XML files by hand, and it even tells you when you've messed something up. You can choose which pieces to include with your own application; you're not committed to dragging around a bunch of unnecessary code.

As an example of what you can do with EntLib, 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% 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).

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.

Whether you just want some tested code to handle certain tasks, need examples of unit testing patterns, or want a framework to build on, the Enterprise Library should be a valuable addition to many .NET applications. Not bad for free! I'm looking forward to using it to eliminate some old and cobwebby code from some of my early .NET efforts myself.

About the Author

Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.