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

Books Details :

Author :Len Fenster
Paperback: 736 pages
Publisher: Addison-Wesley Professional; 1st edition (June 9, 2006)
Language: English
ISBN: 0321334213
Product Dimensions: 9.4 x 7.3 x 1.4 inches



From the Back Cover

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.

About 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.

Excerpt. © Reprinted by permission. All rights reserved.

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.

Spotlight Reviews :

Reviewer: W Boudville (US)
You might think of Microsoft 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.