To read the article online, visit http://www.4GuysFromRolla.com/articles/022305-1.aspx

An Introduction to the Microsoft Enterprise Library

By Scott Mitchell


Introduction


One of Microsoft's efforts over the past couple of years has been to provide developers with useful code libraries that illustrate best practices. To achieve this goal the Patterns and Practices Group has been tasked with developing numerous application blocks, which are open-source libraries aimed at solving common tasks. As discussed in a previous 4Guys article, An Introduction and Overview of the Microsoft Application Blocks, the aim of the application blocks is to reduce development cost and increase confidence. Costs are reduced because integrating the application blocks into a project saves the development time that would otherwise be required to build the functionality, and confidence in the application is increased because the application blocks are well tested and have been used by thousands of developers around the world, meaning any bugs are likely to have been discovered and squashed.

Past articles on 4Guys have examined two of the existing application blocks, the Data Access Application Block (DAAB) and the Exception Management Application Block (EMAB). The DAAB provided a wrapper class for accessing data from a SQL Server database. It's set of methods essentially reduced data access down to one line of code, thereby reducing the tedious amount of code that it typically required when working with database data. The Exception Management Application Block provides a simple, yet extensible way to record exception information. (For more information on these application blocks be sure to read Examining the Data Access Application Block and Examining the Exception Management Application Block.)

The DAAB and EMAB were only two of a number of application blocks released by the Patterns and Practices Group. While all of the application blocks provided useful techniques for accomplishing common tasks, each application block was, in a way, an island unto itself. There was no shared unity between the application blocks. To rectify this, in January 2005 the Patterns and Practices Group released the Enterprise Library, a collection of seven application blocks that share a common design and code base.

This article provides an overview of the Enterprise Library along with a quick demo showing how to use the new Data Access Application Block in an ASP.NET Web application.

An Overview of the Enterprise Library


The previous application blocks created by the Patterns and Practices Group were designed independently of one another, meaning that each application block had its own code for accomplishing tasks common to all application blocks. For example, both the Data Access Application Block and the Exception Management Application Block can read data from the Web.config or App.config configuration files to determine their behavior. Furthermore, since each application block was developed separately from the other, the design goals were not necessarily unified. For example, the Exception Management Application Block (EMAB) was designed to provide an extensible interface to any medium for recording exception information. By default, the EMAB recorded exception information in the Event Log, but a developer could easily modify the EMAB to record exception information in a custom database table instead. The Data Access Application Block, however, was initially designed to only work with a specific data provider - Microsoft SQL Server - and did not provide a mechanism for specifying a different data provider (such as Oracle, Access, DB2, or other data stores).

The Enterprise Library reconciles the rift between the various application blocks, providing a more unified collection of seven different application blocks. From the Enterprise Library home page, the seven application blocks are:

  • Caching Application Block - this application block allows developers to incorporate a local cache in their applications.
  • Configuration Application Block - this application block allows applications to read and write configuration information.
  • Data Access Application Block - this application block allows developers to incorporate standard database functionality in their applications. (See Working with the Enterprise Library's Data Access Application Block for more information on using the DAAB!)
  • Cryptography Application Block - this application block allows developers to include encryption and hashing functionality in their applications.
  • Exception Handling Application Block - this application block allows developers and policy makers to create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications.
  • Logging and Instrumentation Application Block - this application block allows developers to incorporate standard logging and instrumentation functionality in their applications.
  • Security Application Block - this application block allows developers to incorporate security functionality in their applications. Applications can use the application block in a variety of situations, such as authenticating and authorizing users against a database, retrieving role and profile information, and caching user profile information.
By combining the application blocks into a single Enterprise Library, the applications blocks provide a higher degree of consistency. Each of the application blocks uses similar design patterns and share similar deployment and configuration requirements. Do keep in mind that using the Enterprise Library in an application does not require that all seven application blocks be used. You can pick and choose the application blocks from the Enterprise Library that are pertinent to your particular application's needs.

The Enterprise Library illustrates Microsoft's recommended practices in not only the actual code of the application blocks, but also in testing and operations. Each application block provides numerous unit tests that can be run to verify the code's correctness, and to ensure correctness when extending the code to meet your company's custom needs. (For more on unit testing be sure to read Test Driven Development Using NUnit in C#.) Additionally, the application blocks use instrumentation through performance counters, Event Log entries, and WMI events to enable administrators to monitor the health of an application and diagnose problems as they arise. For example, when working with the Data Access Application Block in the Enterprise Library, a plethora of performance counter metrics are maintained, such as number of connections opened per second, and average command execution time.

As with the previous application blocks, the Enterprise Library's application blocks maintain their information in the XML-formatted Web.config or App.config files (depending on whether you are integrating the Enterprise Library into a Web application or desktop application). Previously, the only way to modify the application block settings was to fiddle with the XML settings by hand. The Enterprise Library, however, introduces a GUI tool for maintaining settings information, which we'll examine shortly.

Getting Started with the Enterprise Library


In order to get rolling with the Enterprise Library you'll first need to download the library from Microsoft's site. The download is a near 9 MB file, which includes the complete Enterprise Library application block source code, Quick Start examples, off-line documentation, the GUI tool, and other goodies. (One major annoyance is that in order to download the Enterprise Library you have to register with Microsoft. Boo.) Once you download the Enterprise Library, go ahead and run the downloaded file, which will step you through an installation process. During this installation process you can specify what application blocks to install, if you only want to install a subset of the seven. Upon completion of the installation, the pertinent files should be in the \Program Files\Microsoft Enterprise Library folder.

One step the installation process seems to not do is create the Enterprise Library-specific performance counters. I needed to do this step manually by going to the Start Menu --> Programs --> Microsoft Patterns and Practices --> Enterprise Library --> Install Services. The Install Services batch file ran completed the necessary performance counters. Once these performance counters were created, when going to the Performance monitor through Administrative Tools there were six new items in the Performance Object drop-down list, as shown in the screenshot to the right. For more information on instrumentation, including how to configure the Enterprise Library to not use instrumentation, refer to Instrumentation in Enterprise Library.

Working with the Data Access Application Block


The remainder of this article looks at how to create a simple ASP.NET page that utilizes the Enterprise Library's Data Access Application Block to bind SQL Server database data to a DataGrid in an ASP.NET page. To get started, create a new ASP.NET Web application. In the Web application's WebForm1.aspx page, add a DataGrid from the Toolbox.

At this point, we need to indicate that we want to use the Enterprise Library in our project. To accomplish this, add the Microsoft.Practices.EnterpriseLibrary.Data and Microsoft.Practices.EnterpriseLibrary.Configuration assemblies to the project by right-clicking on the References folder, choosing Add Reference, and then Browsing to the \Program Files\Microsoft Enterprise Library\bin directory and adding the Microsoft.Practices.EnterpriseLibrary.Data.dll and Microsoft.Practices.EnterpriseLibrary.Configuration.dll files. Next, in the code-behind class, add at the top the following two Imports statements:

Imports Microsoft.Practices.EnterpriseLibrary.Data
Imports Microsoft.Practices.EnterpriseLibrary.Data.Sql

Next, add the following code to the Page_Load event handler:

Dim db As Database = DatabaseFactory.CreateDatabase()

Dim sqlCommand As String = ... SQL query, like: "SELECT * FROM TableName" ...
Dim dbCommandWrapper As DBCommandWrapper = db.GetSqlStringCommandWrapper(sqlCommand)

DataGridID.DataSource = db.ExecuteReader(dbCommandWrapper)
DataGridID.DataBind()

Note that the code to retrieve database data does not provide any information about the data store to use. That is, there's no connection string. No hint at if we are using SQL Server or Oracle or some other data store. Rather, everything is referred to via an abstract object. We have a Database object. We specify the command to execute and get back its results via the ExecuteReader() method. (The complete Data Access Application Block API can be found in the Enterprise Library documentation and studied in more depth through the Quick Starts; a future 4Guys article will dive into the Data Access Application Block in much greater detail.) All of the database specific information is stored in a separate configuration file which can be created and tweaked through the GUI tools provided by the Enterprise Library.

To load the GUI tool, go to the Start Menu --> Programs --> Microsoft Patterns and Practices --> Enterprise Library --> Enterprise Library Configuration. You can then open the configuration for your Web application by going to the File menu, choosing Open Application, and browsing to your Web application's Web.config file. Once you have selected this file, the GUI tool will load in a tree node titled Application. Right-click this and choose New --> Data Access Application Block. This will add two children nodes: Configuration Application Block and Data Access Application Block, as shown in the screenshot to the left.

The Configuration Application Block settings will be saved to the Web.config file. The Data Access Application Block settings will be saved to a separate file, dataConfiguration.config. To specify the database's connection string information, expand the Sql Connection String node. For the connection string you can specify an arbitrary number of parameters. These parameters are concatenated together to form the complete connection string used to connect to the data store. By default, the connection string contains three parameters: database, server, and Integrated Security. You can add additional parameters if needed (for example, rather than using Integrated Security, you might require a specific User ID and Password parameter passed through the connection string).

Once you have the configuration information specified, compile your Web application and visit the Web page through a browser. If you configured everything correctly you should see the database data specified by the SQL query used in the page's DataGrid.

Conclusion


The Enterprise Library is a more unified collection of application blocks from Microsoft's Patterns and Practices Group. The application blocks shipped with the Enterprise Library have been updated to utilize a shared common code base and similar semantics and syntax. The Enterprise Library is the next step in the evolution of the application blocks and provides an easy mechanism to accomplish common code tasks using libraries designed to showcase best practices.

This article provided a high-level overview of the Enterprise Library and provided a quick peek into using the Data Access Application Block. Future articles, such as Working with the Enterprise Library's Data Access Application Block will delve into the various application blocks in more detail.

By integrating the Enterprise Library into new and existing applications, you can drastically reduce the amount of code you need to write to accomplish common coding scenarios.

Happy Programming!

  • By Scott Mitchell

  • Article Information
    Article Title: ASP.NET.An Introduction to the Microsoft Enterprise Library
    Article Author: Scott Mitchell
    Published Date: February 23, 2005
    Article URL: http://www.4GuysFromRolla.com/articles/022305-1.aspx


    Copyright 2014 QuinStreet Inc. All Rights Reserved.
    Legal Notices, Licensing, Permissions, Privacy Policy.
    Advertise | Newsletters | E-mail Offers