Review: patterns & practices Enterprise Library
patterns & practices Enterprise Library
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 =
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.
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.