BN.com Gift Guide

Effective Use of Microsoft Application Blocks: Building Blocks for Creating Enterprise Applications and Services (Microsoft .NET Development Series)

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (8) from $1.99   
  • New (2) from $39.09   
  • Used (6) from $1.99   

Overview

Writing robust enterprise applications presents a special challenge for developers, but Microsoft has addressed that challenge with the free, downloadable Enterprise Library for the .NET Framework.

Enterprise Library is a collection of application blocks and guidance documents that together provide functionality common to enterprise applications; each application block includes full source code. Lacking in the guidance provided by Microsoft is an overall roadmap to the process of using the application blocks. Effective Use of Microsoft Enterprise Library is that roadmap.

Microsoft application development lead architect Len Fenster explains exactly how to build applications using Enterprise Library application blocks. Fenster covers all seven application blocks as implemented for .NET Framework 1.1, shows how to develop and use a new application block, and explains how Enterprise Library is changing for .NET Framework 2.0.

Readers will learn

  • How the Configuration Application Block is designed and can be used at runtime to easily read and write configuration data
  • How the Configuration Application Block works at design time for all blocks
  • How to use the Data Access Block to create a portable data layer
  • How to use the Exception Handling Application Block to implement a policy-driven, application-wide exception handling system
  • How to use the Logging and Instrumentation Application Block to log and instrument messages independent of the message destination
  • How to add authentication, authorization, role membership, security cache, and profile membership features to an application with the Security Application Block
  • How to use the Cryptography Application Block to add functionality to encrypt and decrypt data and create and compare hashes
  • How to build your own application block and providers that “snap” right into Enterprise Library

Whether you plan to extend Enterprise Library for your organization, or just use the existing application blocks to add functionality to your architecture in a consistent, extensible, integrated way, this book will guide you through the complexities and help you find a clear path to success.

Read More Show Less

Product Details

  • ISBN-13: 9780321334213
  • Publisher: Addison-Wesley
  • Publication date: 6/30/2006
  • Series: Microsoft .NET Development Series
  • Edition description: New Edition
  • Pages: 736
  • Product dimensions: 6.90 (w) x 9.20 (h) x 1.37 (d)

Meet the Author

Len Fenster is the lead architect for .NET Development for Microsoft Consulting Service’s U.S. East Region. During his last eight years at Microsoft, he has focused on helping many enterprises create robust applications based on Microsoft technology. Most recently, Len has been working with the Microsoft patterns & practices team on the next version of Enterprise Library. Even before his career with Microsoft, Len led a global team of developers and architects that built distributed applications based on Microsoft technologies. Since the advent of .NET, Len has served as an enterprise architect for Microsoft Consulting Services and has leveraged his considerable experience to help many enterprises incorporate .NET into their own technology strategies. Len speaks on a regular basis to companies and at architecture forums about architecting solutions based on .NET and service oriented architecture.

Read More Show Less

Read an Excerpt

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.1 Also, the Caching Application Block is an implementation of the guidance prescribed in the Caching Architecture Guide for .NET Framework Applications.2 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.


Read More Show Less

Table of Contents

Figures xv

Tables xxiii

Foreword xxv

Preface xxix

Acknowledgments xli

About the Author xliii

Chapter 1: The Configuration Application Block Runtime 1

What Is the Configuration Application Block? 2

Design of the Configuration Application Block Runtime 3

Developing with the Configuration Application Block 52

Summary 59

Chapter 2: The Configuration Application Block Design-Time 61

Configuration and the Enterprise Library Configuration Tool 62

Behind the Configuration Design-Time 84

Example: Design-Time Configuration 100

Summary 107

Chapter 3: The Data Access Application Block 109

What Is the Data Access Application Block? 110

Design of the Data Access Application Block 112

Using the Data Access Application Block’s API 138

Summary 175

Chapter 4: The Caching Application Block 177

What Is the Caching Application Block? 178

The Design of the Caching Application Block 183

Developing with the Caching Application Block 220

Summary 240

Chapter 5: The Exception Handling Application Block 241

What Is the Exception Handling Application Block? 242

The Design of the Exception Handling Application Block 247

Developing with the Exception Handling Application Block 290

Summary 304

Chapter 6: The Logging and Instrumentation Application Block 307

What Is the Logging and Instrumentation Application Block? 308

Design of the Logging and Instrumentation Application Block 310

Developing with the Logging and Instrumentation Application Block 376

Summary 394

Chapter 7: The Security Application Block 397

What Is the Security Application Block? 399

Design of the Security Application Block 400

Developing with the Security Application Block 457

Summary 484

Chapter 8: The Cryptography Application Block 487

What Is the Cryptography Application Block? 488

.NET Cryptography 489

Design of the Cryptography Application Block 492

Developing with the Cryptography Application Block 509

Summary 524

Chapter 9: Building an Application Block 525

Vision and Design Goals 526

Core Functionality 529

Pluggable Providers 530

Factories 540

Runtime Configuration 543

Design-Time Configuration 556

Unit Tests 574

Quick Start Application 576

Summary 576

Appendix A: The Data Mapping Application Block 579

Design of the Data Mapping Application Block 580

Developing with the Data Mapping Application Block 595

Summary 619

Appendix B: Creating a .NET Managed Data Provider 621

The IDataParameter Interface 622

The IDataParameterCollection Interface 625

The IDataReader Interface 629

The IDbCommand Interface 633

The IDbConnection and ICloneable Interfaces 637

The IDbDataAdapter Interface 642

The IDbTransaction Interface 647

Appendix C: Enterprise Library for the .NET Framework 2.0 651

The Core 651

Data Access 657

Logging 658

Security 659

Index 661

Read More Show Less

Preface

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, and services 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 XML files and testing the results at runtime. This was one of the most common problems that users of the original blocks faced when trying to use them.
  • 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 XML files to get an application block to function correctly.
    • 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.1 Also, the Caching Application Block is an implementation of the guidance prescribed in the Caching Architecture Guide for .NET Framework Applications. 2 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.
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted July 9, 2006

    more powerful and modular code blocks

    You might think of MS Enterprise Library as a refactoring of many tasks common to applications. These could be for standalone machines or perhaps the application offers a network service, like a Web Service. Fenster describes how MS reworked earlier generations of application blocks into a more consistent offering, presented here. There have been numerous improvements to make your programming life easier. A key plus is simply not having to edit an XML file that describes the configuration of an application, in order to change and test a new configuration. Instead, there is now an Enterprise Library Configuration Tool. This actually reads and writes to the XML files. Much overdue. Your interaction is now easier to perform, and more robust. Manual editing of those files is highly error prone. Using the tool is easy and intuitive, as shown in many screen shots. Not so different from changing Registry values, which you may well have already done, if you work with Microsoft operating systems. The book also offers many code examples, typically written in both C# and VB. These illustrate how to use the Enterprise Library. The style is a little verbose, a function of both the authors' programming styles and the naming conventions of EL. Caused by a natural tendency to use descriptive names for classes and fields (variables). Anyway, the examples in each chapter demonstrate the modular nature of EL. So that you can easily add in a Security Application Block or a Caching Application Block, say. And possibly modify these for your situation. The overall claim is that all this is far simpler than in the past.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)