Effective Use of Microsoft Enterprise Library: Building Blocks for Creating Enterprise Applications and Services [NOOK Book]

Developing applications that fit the needs of many enterprises is of keen interest to CIOs, CTOs, architects, and developers because it typically requires many resources in terms of time and money to develop the core foundational services needed to support these applications. Microsoft has provided guidance for developing these services and code for supporting them. Effective Use of Microsoft Enterprise Library fills the void on how to “put all the blocks together.” With this void filled, architects and developers will be equipped to create solid Service-Oriented Architectures (SOAs) based on the Microsoft recommended best practices in an easy and repeatable manner.

How, you ask? Read on.

Today many companies are faced not only with the challenge of how to create a robust application that leverages as many of the features and functions of Microsoft .NET as they can, but they are also faced with the challenge of architecting these applications so that they can reap the benefits that Service-Oriented Architectures are promising to deliver both now and in the future. Imagine helping your child to create a model of the Sphinx from a box of several hundred random Lego blocks and you might get a good sense of an architect’s emotions when first faced with the prospect of designing an enterprise-level application for a particular CxO.

Microsoft provides help, though, by delivering guidance on how to architect enterprise-level applications so that they can leverage the features and functions of .NET. It provides this help in the form of Prescriptive Architecture Guidance (PAG) documents. PAG documents detail the different layers, components, andservices that architects should consider when designing their applications. Think of the PAGs as the picture of the Sphinx on the Lego blocks box. Microsoft also provides the Lego blocks—in the form of the application blocks for .NET. An application block is code that implements one of the components or services in one of the layers that make up an application.

So, what’s the problem?

The problem is that there is no instruction manual or documented process for using the Lego blocks to create the application blocks. With which block should you start? Should all the blocks be used? Are there blocks missing from the box? How should they best be assembled together?

This book will serve as the instruction manual for how to take the blocks that Microsoft provides to create the picture on the box. This book will help you reshape some of the blocks as needed and see how new blocks can be created. It also looks at the tools Microsoft provides to help you fit the blocks together and where the new initiatives from Microsoft around Service-Oriented Architecture fit with the current application blocks for .NET. A Brief History of Application Blocks

The benefits associated with reusing software assets have been touted for many years. Today developers spend a significant amount of time and energy searching for software libraries or code that provides functionality they need in an effort to avoid “reinventing the wheel.” It is commonplace for developers to first search the Internet for code samples or reusable software libraries with the thought that “this must have been done before.” Sometimes solutions can be located; other times they cannot. However, even when software libraries that solve common application problems can be located, using them is not without its challenges. The design and quality of an asset, as well as the future direction of that asset, must be assessed. Any dependencies upon which the asset relies must also be evaluated to determine whether using it will cause a company to move away from its own strategic vision.

The Microsoft application blocks were intended to help by providing a library of core assets needed for most enterprise applications. This began with the introduction of the original Data Access Application Block in April 2002. The block was popular because it was simple to understand (it had a very simple interface and no dependencies) and it covered the majority of common operations most projects required for accessing a Microsoft SQL Server database.

Over the next few years, more application blocks were introduced; however, those that followed the Data Access Application Block were met with varying degrees of acceptance. Overall, each application block was considered successful, but as more and more application blocks were created, issues began to arise about using them. These issues revolved around the following matters.

• Consistency. The application blocks were created by different teams at Microsoft over several years with no overall guidelines for consistency. The result was that application blocks varied widely in their approach and packaging. Users of the application blocks found it difficult to understand how each new block fit together. Additionally, because the blocks were inconsistent in their approach, many users found it difficult to get them to work together in the same project.
• Configuration. Most of the application blocks relied on complex configuration with little or no tooling support or validation that could help configure the application correctly. Configuring an application block entailed manually creating and modifying
• Complexity. Many of the application blocks that followed the Data Access Application Block were difficult to understand. Yet to become productive with an application block, a developer needed to quickly ramp up by understanding how to configure, develop, and extend the block. There was a lack of samples and tutorials that could help a developer get up to speed very quickly on an application block. Additionally, the documentation that was provided with the application blocks did not convey enough information for most developers to understand how to use the blocks.
• Dependencies. Companies sometimes wanted to use a block but found that they didn’t want to accept the dependencies of that application block. Many times an application block had a hard dependency on other application blocks. For example, many blocks relied on the Exception Management Application Block. However, if an enterprise had no desire to use the Exception Management Application Block, it had to choose between removing the dependency manually or not using the application block at all. Also, the original Logging Application Block had a dependency on the Enterprise Instrumentation Framework (EIF). Users who didn’t want to use the EIF could not use the logging block.

Enterprise Library is the evolution of the application blocks. It is not a product from Microsoft insomuch that you don’t purchase a license for it. Additionally, all the source code for Enterprise Library is released to the public. These facts alone make it much different from any product that Microsoft releases. Enterprise Library’s seven application blocks—Configuration, Data Access, Caching, Exception Handling, Logging and Instrumentation, Security, and Cryptography—are truly a library that can solve common challenges encountered in enterprise applications. It is not a part of the .NET Framework, but rather it is intended to fill what may be perceived as “gaps” in the Framework until such time that the .NET Framework absorbs those features.

The vision for Enterprise Library was to take the lessons that were learned with the original application blocks to not only create a set of the most fundamental application blocks needed for most enterprise applications, but to create an entire ecosystem in which Microsoft customers, partners, community members, and the patterns & practices team can deliver reusable assets that can be combined into code libraries based on the needs of an enterprise. The core philosophy behind Enterprise Library is defined by four principles that guide the development of all of the application blocks in the library.

• Consistency. Every application block should apply consistent design patterns and implementation approaches. This should make it easy for someone who understands one block to understand and use another block and thus become productive quickly.
• Extensibility. Application blocks must include defined extensibility points that let developers customize the behavior of the blocks by plugging in their own code. The goal is to anticipate the need for extensions and minimize the need to modify the core elements through custom code. By designing an application block for extensibility, the application block is able to adapt to different environments and has a greater chance of “fitting” into an enterprise than it might otherwise have had were it not designed this way.
• Ease of Use. For developers to embrace an application block, it must be easy to use. Therefore, the Enterprise Library team provided

• The Enterprise Library Configuration Tool. As configuring the application blocks proved to be one of the most difficult aspects of usability, a graphical configuration tool was created to improve on this experience. The Configuration Tool makes it much easier to create, modify, remove, and validate configuration information for all of the application blocks that ship with Enterprise Library. This eliminates the need to have to manually modify
• A simpler installation procedure. Setting up a development environment to use any of the application blocks has been made simpler.
• Clear documentation and samples. The documentation for every application block includes key scenarios for how that application block might be used and includes walkthroughs for how to perform the most common tasks.

• Integration. Application blocks should be designed to work well together and tested to ensure that they do. However, it should also be possible to use one application block independently of another one. Throughout Enterprise Library, the integration of application blocks has been designed with the goal of loose coupling. This allows the application block on which another block depends to be completely replaced with another asset without causing any issues to the calling block.

Lastly, it is important to point out that Enterprise Library is intended to serve as architectural guidance embodied in the code. Although it ships with the full source code, thus allowing any user the ability to modify it, care should be given before the block is modified, because each application block is intended to enforce best practices for solving specific challenges common to an enterprise-level application. In fact, in many of the chapters in this book I compare the design for an application block to the guidance that has been published by the Microsoft patterns & practices team. For many of the application blocks, the implementation of the application block is a direct result of following the guidance that lays out the blueprint for that particular block.

For example, the design for the Data Access Application Block focuses on how to use database providers in the data layer of an application. The guidance for this can be found in the Application Architecture for .NET: Designing Applications and Services publication.¹ Also, the Caching Application Block is an implementation of the guidance prescribed in the Caching Architecture Guide for .NET Framework Applications.² The Data Mapping Application Block that I created and provide more detail about in Chapter 9 and Appendix A is intended to be an implementation of the guidance for creating and using data access logic components in a distributed application, which is also promoted in the Architecture for .NET: Designing Applications and Services publication.About This Book

Current .NET developers and architects will be interested in this book because it centers on how to use the Enterprise Library application blocks and recommended best practices from Microsoft to produce enterprise applications. I assume that the reader has experience with either Visual Basic.NET or C#. I have included code samples in both languages at every point that I thought it was important to show how to take advantage of a block or to show how the block works.

I believe that most readers will fall into two groups: those who want to know how the Enterprise Library application blocks have been designed and how to take advantage of that design to extend Enterprise Library so that it better fits their needs, and those who just want more information about how to configure and develop an application to use Enterprise Library without any desire to extend any of the application blocks or to create their own.

I have tried to address the needs of both groups in this book. Each chapter addresses either a different application block in Enterprise Library or a specific aspect of Enterprise Library that is important to call out (e.g., the configuration design-time features or how to build a custom application block). For each application block, I begin with a detailed explanation of how the block is designed, the available extension points in that application block, and at least one custom, real-world example of how to create your own extension to that application block. I conclude each chapter with a walkthrough of how to configure the application block and write code to reap the benefits that the block provides.

If you don’t care about the design or extensibility features of a block, you can skip right to the chapter’s final section. If you already know the basics about how to configure and develop an application to use a block but want to know more about how to extend the block to suit your needs, read the first section. If you want to know as much as possible about a block, read the chapter from start to finish.

This book is organized into the following nine chapters and three appendixes.Chapter 1: Configuration Application Block Runtime

This chapter is important for several reasons. It shows how the Configuration Application Block has been designed so that an enterprise application can use it to easily read and write configuration data while remaining completely decoupled from the actual storage type and location where that configuration data is contained. More significantly, however, this chapter is valuable because all the other application blocks that exist in Enterprise Library have a dependency on the Configuration Application Block. The Configuration Application Block is the only application block that is a dependency of the other blocks. Because all of the application blocks are driven by configuration, it is critical to understand the role that this block plays in providing functionality for the other blocks. Many of the real-world extensions to Enterprise Library in this book rely on at least a basic understanding of the configuration runtime. Chapter 2: Configuration Application Block Design-Time

This chapter is also important for all the reasons that the first chapter is important. One of the major design goals for Enterprise Library was to make it easy to configure the application blocks. The design-time features of the Configuration Application Block provide the features that are used to accomplish this goal. When designing extensions to any of the application blocks or creating a completely new application block, it is important to understand how the design-time features of the Configuration Application Block work so that any new extensions can also be made easy to use and configure.Chapter 3: The Data Access Application Block

The Data Access Application Block provides a set of classes and interfaces that encapsulate many of the best practices that Microsoft recommends for designing a data layer. Specifically, Enterprise Library’s Data Access Application Block provides a solution that satisfies the requirements for using database providers to produce cleaner and more manageable code. A new design goal with this version of the Data Access Application Block was to increase the probability that code using this block can be ported between different types of databases. Chapter 4: The Caching Application Block

The Enterprise Library’s Caching Application Block is an implementation of the Solution Blueprint for caching that is promoted in the Caching Architecture Guide for .NET Framework Applications. As a result, it exposes a simple and consistent programming interface that allows the code for an application to be written so that it is indifferent as to the type of caching store that is used. This allows the code for an application to remain unchanged even if the location where the cached data is stored changes.Chapter 5: The Exception Handling Application Block

Enterprise Library’s Exception Handling Application Block is a policy-driven system that lets an administrator determine how specific exceptions are handled in an application and a developer concentrate on why and where exceptions should be handled. The block is an implementation of the best practices promoted by the Microsoft patterns & practices team. This application block provides a very simple programming interface so that developers for the application don’t need to be concerned about how an exception gets handled. This allows the code for an application to remain unchanged even if a change is made to the way an exception is handled or exception handlers are added or removed for a particular scenario.Chapter 6: The Logging and Instrumentation Application Block

The Logging and Instrumentation Application Block provides a standard and consistent way to log and instrument messages independent of whether the message is destined for an event log, file, database, MSMQ, or WMI event. This application block is designed to make it easy for developers to incorporate logging and tracing functionality into an application without needing to know anything about how, where, or even if a message gets logged. In this chapter I show how the Logging and Instrumentation Application Block can be extended to provide capabilities to log information to other data sources if the features that are provided out-of-the-box do not fit your needs.Chapter 7: The Security Application Block

The primary design goal for the Security Application Block was to make it easy for an enterprise to add authentication, authorization, role membership, security cache, and profile membership features to their applications. The Security Application Block ships with a relational security database, security database administration console, and security providers for that database that make it easy for an application to add security features without having to rely on some other external user store, for example, Microsoft Active Directory. At the same time, it is understood that many enterprises already have a system in place that stores information about its users, credentials, and roles in the enterprise. The Security Application Block has been designed so that it can easily be extended to meet the needs of these enterprises. In this chapter I show you how to do just that. Chapter 8: The Cryptography Application Block

The Cryptography Application Block makes it easier for developers to add functionality to their applications for encrypting data, decrypting data, and creating and comparing hashes. The Cryptography Application Block uses many of the assets that exist in the .NET Cryptography API, while also eliminating some of the complexities that are associated with using it.Chapter 9: Building an Application Block

All the chapters up until this point show how to extend the features of an application block so that it can fit the particular needs of an enterprise. The extensibility of Enterprise Library, however, does not end with the ability to just extend each application block. The Enterprise Library team expects—in fact, it promotes—the creation of new application blocks that solve the particular needs of enterprises. The application blocks that ship with Enterprise Library solve many of the challenging issues that are faced by most enterprise applications; however, there is no belief that they will solve all of them. If none of the application blocks that ship with Enterprise Library can solve your reoccurring challenge, then it is perfectly reasonable to create a new application block that can solve this need and can serve as a peer to the application blocks that ship with Enterprise Library. In this chapter I walk you through the steps that are needed to create a new application block that will solve your problems.Appendix A: The Data Mapping Application Block

In Chapter 9 I describe the steps to create a new application block. This new block, the Data Mapping Application Block, is intended to make it easier for developers to create data access logic components that subscribe to the best practices as promoted by the Microsoft patterns & practices team. In this appendix I provide details with respect to the design of that application block and how to configure and develop an application to use it. Appendix B: Building a .NET Managed Data Provider

In Chapter 3 I describe the database providers that ship with Enterprise Library and show how to extend the Data Access Application Block by creating a new database provider. A prerequisite for a database provider is the existence of a .NET managed data provider that exposes an implementation for the interfaces that need to be returned by that database provider. In this appendix I show how to create a .NET managed data provider for the rare cases where you need one that does not already exist.Appendix C: Enterprise Library for the .NET Framework 2.0

This book explains the design of Enterprise Library for the .NET Framework 1.1 and how to extend, develop, and configure Enterprise Library’s application blocks. In January 2006, Enterprise Library for the .NET Framework 2.0 was released. In this appendix I highlight the important differences between Enterprise Library for the .NET Framework 1.1 and Enterprise Library for the .NET Framework 2.0.Notes:

1. Found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp.
2. Found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/CachingArch.asp.