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, but 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.