Introduction to the Policy Injection Application Block
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
|The latest Enterprise Library information can be found at the Enterprise Library site.|
This topic includes a series of brief sections that provide information that will help you decide if the Policy Injection Application Block is suitable for your requirements. This topic includes the following sections:
- Common Scenarios
- Highlights of the Policy Injection Application Block
- Determining When to Use the Policy Injection Application Block
- Limitations of the Policy Injection Application Block
- Alternatives to Using the Policy Injection Application Block
In addition to this introductory material, the documentation contains the following topics:
- Developing Applications Using the Policy Injection Application Block. This topic first explains how to configure the Policy Injection Application Block and add it to your application. It then explains how you can use attribute-based policy injection and how to instantiate objects when using the Policy Injection Application Block.
- Key Scenarios. This section explores some typical scenarios for using the Policy Injection handlers and demonstrates how to use the application block to perform typical tasks such as creating object instances and applying policies.
- Design of the Policy Injection Application Block. This topic explains the decisions that went into designing the application block and the rationale behind those decisions.
- Extending and Modifying the Policy Injection Application Block. This topic explains how to extend the application block by adding your own custom handlers and matching rules, or by replacing the interception mechanism.
- Deployment and Operations. This topic explains how to deploy and update the application block assemblies.
- Policy Injection QuickStarts. This topic explains how to install and configure the QuickStart applications. It also contains a walkthrough that demonstrates how you can use the application block in an ASP.NET application.
For details of the system requirements for the Policy Injection Block, see System Requirements. For details of the dependencies for the Policy Injection Application Block, see Application Block Dependencies.
Applications include a mix of business logic and crosscutting concerns, and the two are typically intermingled—which can make the code harder to read and maintain. Each task or feature of an application is referred to as a "concern." Concerns that implement the features of an object within the application, such as the business logic, are core concerns. Crosscutting concerns are the necessary tasks, features, or processes that are common across different objects—for example, logging, authorization, validation, and instrumentation. The purpose of the Policy Injection Application Block is to separate the core concerns and crosscutting concerns.
Developers can use the Policy Injection Application Block to specify crosscutting behavior of objects in terms of a set of policies. A policy is the combination of a series of handlers that execute when client code calls methods of the class and—with the exception of attribute-based policies—a series of matching rules that select the classes and class members (methods and properties) to which the application block attaches the handlers. Attribute-based policies rely on attributes directly applied to the members of the target class to identify those to which the application block will apply policies. The result is a mechanism for declaratively applying a chain of handlers to members of the target class instance. This chain of handlers is a pipeline.
Highlights of the Policy Injection Application Block
The Policy Injection Application Block addresses the following scenarios:
- Building applications from objects that require encapsulation and separation to provide the most benefit from independence in operation, and the maximum capability for reuse
- Managing crosscutting concerns that may otherwise affect the independence of objects that require access to common features (such as logging or validation)
- Allowing 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
- Minimizing 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
- Making 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
- Reducing development time and cost, and minimizing bugs in complex applications that use common and shared tasks and services
Determining When to Use the Policy Injection Application Block
Like all interception technologies, the Policy Injection Application Block imposes some extra processing requirements on applications—although the design of the application block minimizes these as much as possible. The features that the Policy Injection Application Block provides, and the opportunities it offers to simplify coding solutions that minimize crosscutting concerns and promote manageability, usually outweigh the small extra processing requirement.
Factors to keep in mind when evaluating the application block, and when comparing the capabilities with other technologies and approaches for implementing policy injection through interception, are the following:
- The Policy Injection Application Block provides 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.
- The Policy Injection Application Block provides 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.
- The Policy Injection Application Block uses best practice techniques to implement the core features, yet it is flexible and extensible so that developers can create custom matching rules and handlers, and even completely replace the default interception mechanism, in order to maximize performance in specific scenarios that do not require all the general-purpose features of the application block.
- The default interception mechanism in the Policy Injection Application Block allows developers to reuse existing object instances (if they meet the requirements to be "interceptable"). 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 object creation and wrapping factory methods provided by the Policy Injection Application Block are intelligent, in that they examine the current application configuration to determine whether a handler pipeline is required before creating a proxy for an object. If there are no matching rules or directly applied attributes that select this object, and therefore there is no requirement for a handler pipeline, the factory methods automatically return an instance of the object instead of a proxy to the object.
Limitations of the Policy Injection Application Block
Some functional limitations arise when using the Policy Injection Application Block to call routines that implement crosscutting concerns (such as validation, logging, and authorization) from handlers instead of directly from custom application code:
- Handlers in a pipeline have access only to the call message passed along the pipeline. Code in a handler cannot call other business logic routines. For example, the code in a handler that logs method calls cannot easily obtain and log additional context information that is not in the call message, whereas it is easy to do this when using traditional coding techniques.
- The interception techniques used by the Policy Injection Application Block can only inject policies (in other words, create and connect handler pipelines) for public methods and properties. It cannot inject policies for class constructors or non-public members of classes.
- By default, the Policy Injection Application Block can only intercept and inject policies for objects that meet the requirements of the built-in interception mechanism. This means that objects must either inherit from the abstract base class MarshalByRefObject or implement a known interface containing the methods and properties for which policies are required. However, you can replace the default interception mechanism with a custom mechanism you create to meet the requirements of the types of objects you need to intercept.
- Matching rules can only select target classes and members based on static information about the classes; they cannot use run-time information such as parameter values.
- The application block caches policies as it initializes; the matching rules are not re-evaluated on each call. Therefore, matching rules cannot contain dynamic logic that changes over time.
- The application block reuses handler instances in different pipelines in order to minimize the number of objects it must create. However, this means that handlers cannot store per-call state internally. If they did, problems would occur in multi-threaded applications where multiple calls passing through the same handler could corrupt the internal state.
Alternatives to Using the Policy Injection Application Block
Alternatives to using the Policy Injection Application Block may include the following:
- The Unity Application Block included with Enterprise Library
- One of the aspect-oriented programming (AOP) frameworks available from third-party suppliers, such as the Spring Framework (http://www.springframework.net/)
- Traditional techniques for adding features, such as logging, caching, authorization and validation to the members of a class—for example, using custom code or the ASP.NET server controls