Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

When to Use the Policy Injection Application Block

Retired Content

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.

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.

Retired Content

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.
Show:
© 2015 Microsoft