:item1: Caching Application Block

The Enterprise Library Caching Application Block, version 1.0, lets developers incorporate a local cache in their applications. It supports both an in-memory cache and, optionally, a backing store that can either be the Enterprise Library Data Access Application Block or isolated storage. The application block can be used without modification and provides all the functionality needed to retrieve, add, and remove cached data. Configurable expiration and scavenging policies are also part of the application block’s functionality.

When building enterprise-scale distributed applications, architects and developers are faced with many challenges. Caching can help you overcome some of these challenges, including the following:

Performance. Caching improves application performance by storing relevant data as close as possible to the data consumer. This avoids repetitive data creation, processing, and transportation.

Scalability. Storing information in a cache helps save resources and increases scalability as the demands on the application increase.

Availability. By storing data in a local cache, the application may be able to survive system failures such as network latency, Web service problems, and hardware failures.

:item1: Configuration Application Block

Almost every application requires some form of configuration information. This information can be as simple as a database connection string or as complex as multipart and hierarchical user preference information. How and where to store an application’s configuration data are questions you often face as a developer. Typical solutions include the following:

Using configuration files such as XML files or Windows .ini files

Using the Windows registry

Using databases such as Microsoft SQL Server

Each of these alternatives has its strengths and weaknesses; there is no solution that is best in every situation. In a single application, you may have to adopt more than one approach to accommodate the different types of configuration data that your application needs. For example, if your application runs in different environments, you may need to support multiple configuration storage solutions. Other important factors to consider include ensuring the security and integrity of your application’s configuration data and minimizing the storage solution’s impact on the application’s performance.

The Enterprise Library Configuration Application Block, version 1.0, addresses these issues and provides a solution that you can use across all of your applications to manage configuration data. Specifically, the Configuration Application Block provides a flexible data model, a simple method for retrieving configuration data, and extensibility.

The Configuration Application Block decouples the ability to read and write configuration data from the specifics of the underlying data store. It does this by using storage providers and transformers to transfer data between the application and the physical store. Storage providers are objects that can read or write to a particular physical store, such as an XML file or a SQL database. Transformers translate the configuration information between the form the application expects (for example a set of objects) and the form the storage provider requires (for example an XML document). The application block is packaged with an XML file storage provider and an XML serializer transformer.

You define the storage provider and transformer in a file that contains configuration metadata. Typically, this file is either the Machine.config file, the App.config file, or the Web.config file. The metadata includes information such as the name of the configuration section, the storage location, and the type names of the objects to be used when reading or writing configuration settings. This means that you can change from one type of store to another by changing the information in the file. There is no need to rewrite your application.

Similarly, you can change the attributes of your store, such as its location, by changing the same file. Again, there is no need to modify your application code. Deciding where to store configuration data can be done during deployment and operation.

:item1: Data Access Application Block

The Enterprise Library Data Access Application Block, version 1.0, simplifies development tasks that implement common data access functionality. Applications can use the application block in a variety of situations, such as reading data for display, obtaining data to pass through application layers, and submitting changed data back to the database system. The application block includes support for both stored procedures and in-line SQL, and common housekeeping tasks such as managing connections and creating and caching parameters are encapsulated in the application block’s methods. In other words, the Data Access Application Block provides access to the most frequently used features of ADO.NET.

The application block also facilitates the development of portable application code, allowing the code to remain uniform across multiple database servers, including Microsoft SQL Server, Oracle, and DB2. It does so by using an abstract base class that defines a common interface and provides much of the implementation for the data access methods, Applications written for one type of database—such as SQL Server—look the same as applications written for another type of database, such as Oracle. By using the Data Access Application Block and by following the guidelines in this document, your code remains mostly portable.

Another feature is that application code can refer to particular databases by name, such as “Customer” or “Inventory.” Changing the name in the application configuration allows developers to use their applications with different database configurations, without having to recompile their code.

The Data Access Application Block has the following features:

It reduces the need to write boilerplate code to perform standard tasks.

It helps maintain consistent data access practices, both in an application and across the enterprise.

It reduces difficulties in changing the physical database target.

It relieves developers from learning different programming models for different types of databases.

It reduces the amount of code that needs to be rewritten when porting applications to different types of databases.

:item1: Cryptography Application Block

The Microsoft Enterprise Library Cryptography Application Block, version 1.0, simplifies how developers incorporate cryptography functionality in their applications. Applications can use the application block for a variety of tasks, such as encrypting information, creating a hash from data, and comparing hash values to verify that data has not been altered.

The Cryptography Application Block has the following features:

It reduces the requirement to write boilerplate code to perform standard tasks, providing implementations that you can use to solve common application cryptography problems.

It helps maintain consistent cryptography practices, both in an application and across the enterprise.

It eases the learning curve for developers by using a consistent architectural model across the various areas of functionality that are provided.

It provides implementations that you can use to solve common application cryptography problems.

It is extensible; supporting additional implementations of cryptography providers.

:item1: Exception Handling Application Block

The Enterprise Library Exception Handling Application Block, version 1.0, lets developers and policy makers create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications. It does this in the following ways:

It supports exception handling throughout an application’s architectural layers and is not limited to service interface boundaries.

It enables exception-handling policies to be defined and maintained at the administrative level so that policy makers, who may be system administrators as well as developers, can define how to handle exceptions. They can maintain and modify the sets of rules that govern exception handling without changing the block’s application code.

It provides commonly used exception-handling functions, such as the ability to log exception information, the ability to hide sensitive information by replacing the original exception with another exception, and the ability to add contextual information to an exception by wrapping the original exception inside another exception. These functions are encapsulated in .NET classes named exception handlers.

It can combine exception handlers to produce the desired response to an exception, such as logging exception information followed by replacing the original exception with another.

It lets developers create their own exception handlers.

It invokes exception handlers in a consistent manner. This means that the handlers can be used in multiple places in and across applications.

:item1: Logging and Instrumentation Application Block

The Enterprise Library Logging and Instrumentation Application Block, version 1.0, lets developers incorporate standard logging and instrumentation functionality in their applications. Applications can use the Logging and Instrumentation Block to log events to a variety of locations:

The event log

E-mail messages

A database

A message queue

A file

WMI

The Logging and Instrumentation Application Block helps with application development in a number of ways:

It helps maintain consistent logging and instrumentation practices, both within an application and across the enterprise.

It eases the learning curve for developers by using a consistent architectural model.

It provides implementations that you can use to solve common application logging and instrumentation problems.

It is extensible, supporting custom implementations of formatters and event sinks.

:item1: Security Application Block

The Microsoft Enterprise Library Security Application Block, version 1.0, helps developers implement common security-related functionality in their applications. Applications can use the application block in a variety of situations, such as authenticating and authorizing users against a database, retrieving role and profile information, and caching user profile information. The Security Application Block has the following features:

It reduces the requirement to write boilerplate code to perform standard tasks.

It helps maintain consistent security practices, both within an application and across the enterprise.

It eases the learning curve for developers by using a consistent architectural model across the various areas of functionality provided.

It provides implementations that you can use to solve common application security problems.

It is extensible; it supports custom implementations of security providers.