This project is read-only.

Cheat Sheet: p&p Enterprise Library

J.D. Meier, Alex Homer, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher, Akshay Bogawat

Overview

This guidance describes the patterns & practice Enterprise Library, and explains how you can use it in your applications to quickly and simply implement common tasks and better manage cross-cutting concerns such as logging, exception handling, and data access.
Enterprise Library Frame
Enterprise Library consists of a collection of application blocks and a set of core features such as object generation and configuration mechanisms. All of these are reusable software components designed to assist developers with common enterprise development challenges.

The goals of Enterprise Library are the following:
  • Consistency. All Enterprise Library application blocks feature consistent design patterns and implementation approaches.
  • Extensibility. All application blocks include defined extensibility points that allow developers to customize the behavior of the application blocks by adding their own code.
  • Ease of use. Enterprise Library offers numerous usability improvements, including a graphical configuration tool, a simpler installation procedure, and clearer and more complete documentation and samples.
  • Integration. Enterprise Library application blocks are designed to work well together and are tested to make sure that they do. It is also possible to use the application blocks individually.

Application Block Description
Caching Application Block Helps developers to incorporate a local cache in their applications. It supports both an in-memory cache and, optionally, a backing store that can either be a database or isolated storage. The block provides all the functionality needed to retrieve, add, and remove cached data, and supports configurable expiration and scavenging policies.
Cryptography Application Block Simplifies how developers incorporate cryptographic 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.
Data Access Application Block Simplifies development tasks that implement common data access functionality, such as reading data for display, passing data through application layers, and submitting changed data back to the database system. The block includes support for both stored procedures and in-line SQL, and provides access to the most often used features of ADO.NET in simple-to-use classes.
Exception Handling Application Block Helps developers and policy makers to create a consistent strategy for processing exceptions that occur in all architectural layers of an enterprise application. It can log exception information, hide sensitive information by replacing the original exception with another exception, and maintain contextual information for an exception by wrapping the original exception inside another exception.
Logging Application Block Simplifies the implementation of common logging functions. The block can write information to the Windows Event Log, an email message, a database, Windows Message Queuing, a text file, a WMI event, or a custom location.
The Policy Injection Application Block Helps developers to better manage crosscutting concerns, maximize separation of concerns, and encapsulate behavior by automatically applying policies to object instances. Developers define the set of policies for the target classes and their members through configuration or by applying attributes to individual members of the target class.
Security Application Block Helps developers implement common authorization-related functionality in their applications and cache a user's authorization and authentication data. Together with the Microsoft .NET Framework 2.0 features, developers can easily implement common security-related functionality.
Unity Application Block Provides a lightweight, extensible dependency injection container with support for constructor, property, and method call injection. Developers can use it with Enterprise Library to generate both Enterprise Library objects and their own custom business objects, or as a stand-alone DI mechanism.
Validation Application Block Provides useful features that allow developers to implement structured and easy-to-maintain validation scenarios in their applications. It includes a library of validators for validating .NET Framework data types, such as null string and number range validators. It also includes composite validators and support for rule sets.


Enterprise Library also contains:
  • Configuration tools that make it easy to add Enterprise Library blocks to an application and specify configuration information. The configuration tools include a stand-alone configuration editor and a configuration tool that integrates with Visual Studio.
  • Common utility functions for tasks such as serialization, used in many places throughout the library and the application blocks and available for developers to use in their code.
  • Instrumentation features that allow developers and administrators to monitor the behavior and performance of the application blocks at run time.
  • Batch files that build the Enterprise Library source code and copy the assemblies to the appropriate locations.
  • Utilities to install the instrumentation required by Enterprise Library.
  • Utilities to create the sample databases used by the Enterprise Library examples and QuickStarts.
  • A full set of QuickStart applications, one for each application block, which demonstrate how you can use the application blocks. They implement common scenarios from each application block and provide links to the relevant sections of the guidance documentation.
  • Full source code for Enterprise Library, including Visual Studio projects and unit tests that developers can use to extend and modify the library and the application blocks. Developers make sure applications still meet the design requirements by running the unit tests and writing new tests.

Caching Application Block

The Caching Application Block is suitable if you encounter any of the following situations:
  • You must repeatedly access static data or data that rarely changes.
  • Data access is expensive in terms of creation, access, or transportation.
  • Data must always be available, even when the source, such as a server, is not available.

The Caching Application Block is optimized for high performance and scalability. Furthermore, it is both thread safe and exception safe. You can extend it to include your own expiration policies and your own backing store. It is designed to work in the most common data-caching situation, which is when the application and the cache exist on the same system. This means that the cache is local and should be used only by that application. When it operates within these guidelines, the application block is ideal for addressing the following requirements:
  • You need a consistent form of caching across different application environments. For example, developers can write similar code to implement caching in application components hosted in Internet Information Services (IIS), Enterprise Services, and smart client environments. Also, the same cache configuration options exist for all environments.
  • You need a configurable and persistent backing store. The block supports both isolated storage and database backing stores. Developers can create additional backing store providers and add them to the block using its configuration settings. The application block can also symmetrically encrypt a cache item's data before it is persisted to a backing store.
  • Changes to the cache configuration settings must not require application source code changes. Developers first write the code that uses one or more named caches. System operators and developers can then configure each of these named caches differently using the Enterprise Library configuration tools.
  • Cache items require any of the following expiration settings: absolute time, sliding time, extended time format (for example, every evening at midnight), file dependency, or never expired.
  • You want to modify the block source code for extensibility or customization.
  • You need multiple Cache managers in a single application.

You can use the Caching Application Block with any of the following application types:
  • Windows Forms.
  • Console application.
  • Windows service.
  • COM+ server.
  • ASP.NET Web application or Web service if you need features not included in the ASP.NET cache.

The following limitations apply to the Caching Application Block:
  • You should deploy the block within a single application domain. Each application domain can have one or multiple caches, either with or without backing stores.
  • Caches cannot be shared among different application domains.
  • Although you can encrypt data cached in the backing stores, the block does not support encryption of data that is cached in memory.
  • The block does not tamper-proofing (signing and verifying items in the cache).

Additional Resources

For more information, see The Caching Application Block at http://msdn.microsoft.com/en-us/library/cc511588.aspx.:

Cryptography Application Block

The Cryptography Application Block is suitable if you encounter any of the following situations:
  • You need to encrypt and decrypt information.
  • You need to create a hash from data.
  • You need to compare hash values to verify that data has not been altered.

The Cryptography Application Block is ideal for addressing the following requirements:
  • You need to reduce the requirement to write boilerplate code to perform standard tasks.
  • You need to maintain consistent cryptography practices, both within an application and across the enterprise.
  • You need to simplify learning for developers by using a consistent architectural model across the various areas of functionality that are provided.
  • You need to solve common application cryptography problems.
  • You need to add or extend implementations of cryptography providers.
  • You need a customizable Key Protection Model.

The following limitations apply to the Cryptography Application Block:
  • The block supports only symmetric algorithms that use the same key for both encryption and decryption.
  • The block does not automatically manage encryption keys and key storage.

Additional Resources

For more information, see Cryptography Application Block at http://msdn.microsoft.com/en-us/library/cc511721.aspx.

Data Access Application Block

The Data Access Application Block is suitable if you encounter any of the following situations:
  • You need to use a DataReader to retrieve multiple rows of data.
  • You need to use a DataSet to retrieve multiple rows of data.
  • You need to execute a command and retrieve the output parameters.
  • You need to execute a command and retrieve a single-value item.
  • You need to perform multiple operations within a transaction.
  • You need to retrieve XML data from a SQL Server.
  • You need to update a database with data contained in a DataSet object.
  • You need to add or extend implementations of database providers.

The Data Access Application Block is ideal for addressing the following requirements:
  • You need simplicity and convenience while helping developers use ADO.NET with best practices.
  • You need to use the functionality provided by ADO.NET 2.0.
  • You need to reduce the requirement for boilerplate code to perform standard tasks.
  • You need to maintain consistent data access practices, both within an application and across the enterprise.
  • You need to reduce the difficulties in changing the database type.
  • You need to relieve developers from learning different programming models for different types of databases.
  • You need to reduce the amount of code that developers must write when they port applications to different types of databases.

The following limitations apply to the Data Access Application Block:
  • The Data Access Application Block is a complement to ADO.NET; it is not a replacement.
  • If your application needs to retrieve data in a specialized way, consider using ADO.NET directly.
  • If your code needs customization to take advantage of features specific to a particular database, consider using ADO.NET directly.

Additional Resources

For more information, see Data Access Application Block at http://msdn.microsoft.com/en-us/library/cc511547.aspx.

Exception Handling Application Block

The Exception Handling Application Block is suitable if you encounter any of the following situations:
  • You need to support exception handling in all architectural layers of an application, not just at service interface boundaries.
  • You need exception handling policies to be defined and maintained at the administrative level and maintain and modify the rules that govern exception handling without changing the application block code.
  • You need to provide 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 maintain contextual information for an exception by wrapping the original exception inside another exception.
  • You need to combine exception handlers to produce the desired response to an exception, such as logging exception information followed by replacing the original exception with another.
  • You need to invoke exception handlers in a consistent manner so that you can handlers can use them in multiple places within and across applications.
  • You need to add or extend implementations of exception handlers.
  • You need to handle exceptions via policies as opposed to simply logging them.

The Exception Handling Application Block is ideal for addressing the following requirements:
  • Logging an Exception
  • Wrapping an Exception
  • Replacing an Exception
  • Propagating an Exception
  • Displaying User-Friendly Messages
  • Notifying the User
  • Assisting Support Staff
  • Shielding Exceptions at WCF Service Boundaries
  • Localization support for Exception messages.

The Exception Handling Application Block allows developers to encapsulate the logic contained in catch statements in application components as reusable exception handlers. The block includes four exception handlers:
  • Wrap handler. This exception handler wraps one exception around another.
  • Replace handler. This exception handler replaces one exception with another.
  • Logging handler. This exception handler formats exception information, such as the message and the stack trace, and passes it to the Enterprise Library Logging Application Block so that it can be published.
  • Fault Contract Exception Handler. This exception handler is designed for use at Windows Communication Foundation (WCF) service boundaries, and generates a new Fault Contract from the exception.

Additional Resources

For more information, see Exception Handling Application Block at http://msdn2.microsoft.com/en-us/library/aa480461.aspx.

Logging Application Block

The Logging Application Block is suitable if you encounter any of the following situations:
  • You need to maintain consistent logging practices, both within an application and across the enterprise.
  • You need to ease the learning curve for developers by using a consistent architectural model.
  • You need to provide implementations that you can use to solve common application logging tasks.
  • You need to add or extend logging implementations and targets.

The Logging Application Block is ideal for addressing the following requirements:
  • You need to populate and log event information
  • You need to include context information in the event
  • You need to trace application activities
  • You need to prevent unauthorized access to sensitive information using access control lists (ACLs) to restrict access to flat files, or you can create a custom formatter that encrypts log information.

The Logging Application Block can write information to a variety of locations including:
  • The Windows Event log
  • An email message
  • A database
  • A message queue
  • A text file
  • A Windows Management Instrumentation (WMI) event
  • Custom locations using application block extension points

The following limitations apply to the Logging Application Block:
  • The block logging formatters do not encrypt logging information.
  • Trace listener destinations receive logging information as clear text.
  • Some of the Logging Application Block listeners fail while running under partial trust.

Additional Resources

For more information, see Logging Application Block at http://msdn.microsoft.com/en-us/library/cc511708.aspx.

The Policy Injection Application Block

The Policy Injection Application Block is suitable if you encounter any of the following situations:
  • You need to separate core concerns and crosscutting concerns.
  • You need to build applications from objects that require encapsulation and separation to provide the most benefit from independence in operation, and the maximum capability for reuse.
  • You need to manage crosscutting concerns that may otherwise affect the independence of objects that require access to common features (such as logging or validation).
  • You need to allow the developer and administrator to configure the behavior of objects in an application through configuration, by adding or removing handlers that execute common tasks or add custom features.
  • You need to minimize the work required and the code that the developer must write to perform common tasks within an application, such as logging, validation, authorization, and instrumentation.
  • You need to make it easy for developers to take advantage of features within the Enterprise Library Core and individual application blocks that implement tasks commonly required in enterprise applications.
  • You need to reduce development time and cost, and minimize bugs in complex applications that use common and shared tasks and services.

The Policy Injection Application Block is ideal for addressing the following requirements:
  • You need a ready-built solution that is easy to implement in new and existing applications, particularly in applications that already take advantage of the features of the Enterprise Library.
  • You need a solution that allows developers, operators, and administrators to create, modify, remove, and fine-tune interception policies though configuration, generally without requiring any changes to the code or recompilation of the application. This limits the chances of introducing errors into the code, simplifies versioning, and reduces downtime.
  • You want to reuse existing object instances. This reduces the requirement for code to generate new object instances and prepare them by setting properties or calling methods, while still allowing handler pipelines to be used for specific members or all members of that class.

The following limitations apply to the Policy Injection Application Block:
  • It uses interception to enable only pre-processing handlers and post-processing handlers.
  • It does not insert code into methods.
  • It does not provide interception for class constructors.
  • Like all interception technologies, it imposes some extra processing requirements on applications—although the design of the block minimizes these as much as possible.
  • Call handlers only have access to the information within the call message, and cannot maintain internal state.
  • Policy injection can only take place for public members of the target class.

Additional Resources

For more information, see Policy Injection Application Block at http://msdn.microsoft.com/en-us/library/cc511729.aspx.

Security Application Block

The Security Application Block is suitable if you encounter any of the following situations:
  • You need to use security-related credentials to perform authorization.
  • You need to cache security-related credentials.
  • You need to obtain a temporary token for an authenticated user.
  • You need to authenticate a user using a token.
  • You need to terminate a user session (expire the token).
  • You need to determine whether a user is authorized to perform a task.

The Security Application Block is ideal for addressing the following requirements:
  • You need to solve common application security problems.
  • You need to reduce the requirement for boilerplate code to perform standard tasks.
  • You need to maintain consistent security practices, both within an application and across the enterprise.
  • You need to ease the learning curve for developers by using a consistent architectural model across the various areas of functionality provided.
  • You need to use custom implementations of security providers.

The following limitations apply to the Security Application Block:
  • The default store for cached security-related information is the Caching Application Block.
  • Although the Caching Application Block can be configured to encrypt cache data in backing stores, the application block does not support encryption of cache data stored in memory.
  • If this threat is significant for your application, you can use an alternate custom caching store provider that supports in-memory encryption.
  • The authorization manager is not supported under partial trust.

Additional Resources

For more information, see Security Application Block at http://msdn.microsoft.com/en-us/library/cc511928.aspx.

Unity Application Block

The Unity Application Block is suitable if you encounter any of the following situations:
  • You need simplified object creation, especially for hierarchical object structures and dependencies, which simplifies application code.
  • You need to abstract requirements by specifying dependencies at run time or in configuration to simplify management of crosscutting concerns.
  • You need to increase flexibility by deferring component configuration to the container.
  • You need a service location capability where clients can store or cache the container. This is especially useful in ASP.NET Web applications where the developers can persist the container in the ASP.NET session or application.

The Unity Application Block is ideal for addressing the following requirements:
  • You need a dependency injection container that supports constructor, property, and method call injection.
  • Your objects and classes may have dependencies on other objects or classes.
  • Your dependencies are complex or require abstraction.
  • You want to take advantage of constructor, method, or property call injection features.
  • You want to manage the lifetime of object instances.
  • You want to be able to configure and change dependencies at run time.
  • You want to be able to cache or persist the dependencies across postbacks in a Web application.

You should not use the Unity Application Block in the following situations:
  • Your objects and classes have no dependencies on other objects or classes.
  • Your dependencies are very simple and do not require abstraction.

The following limitations apply to the Unity Application Block:
  • Dependency injection may have a minor impact on performance.
  • Dependency injection can increase complexity where only simple dependencies exist.

Additional Resources

For more information, see Unity Application Block at http://msdn.microsoft.com/en-us/library/cc511654.aspx.

The Validation Application Block

The Validation Application Block is suitable if you encounter any of the following situations:
  • You need to implement structured and easy-to-maintain validation scenarios in your applications.
  • You need to prevent the injection of malicious data into your application.
  • You need to enforce business rules and to provide responses to user input.
  • You need to validate data several times within the same application using the same rules.
  • You need a library of pre-built validators with a wide range of capabilities.
  • You need to be able to combine validators in complex scenarios.
  • You need to group validators together in a rule set to validate a complex object or graph by composing different validators of different types and applying them to elements in the object graph.
  • You need to validate fields, properties, and nested objects.

The Validation Application Block is ideal for addressing the following requirements:
  • You need to maintain consistent validation practices.
  • You need to validate most standard .NET data types.
  • You need to create validation rules with configuration, attributes, and code.
  • You need to associate multiple rule sets with the same class and with members of that class.
  • You need to apply one or more rule sets when you validate an object.
  • Reuse entity business validation logic.

The Validation Application Block can perform validation and use rule sets in the following three ways:
  • Using configuration.
  • Using attributes.
  • Using code.

The Validation Application Block includes adapters that allow you to use the application block with the following technologies:
  • ASP.NET.
  • Windows Forms.
  • Windows Communications Framework (WCF).

The following limitations apply to the Validation Application Block:
  • Some technologies such as ASP.NET and Windows Forms provide built-in validation features. If your validation logic only needs to be applied within these technologies you may not need to use the application block unless you need to reuse the validation logic.
  • WCF and other applications that use XML data can use XML Schemas to validate messages at the XML level. If your validation logic only needs to be applied within these technologies you may not need to use the application block unless you need to reuse the validation logic.
  • In very simple cases, when you only need to validate a few objects, you may not want to incur the overhead of adding the application block.

Additional Resources

For more information, see Validation Application Block at http://msdn.microsoft.com/en-us/library/cc511802.aspx.

Additional Resources

For more information, see Enterprise Library at http://msdn.microsoft.com/en-us/library/cc467894.aspx.

Last edited Oct 8, 2008 at 7:11 PM by prashantbansode, version 1

Comments

No comments yet.