Interception and Policy Injection

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.

On this page:
Matching Rules | Call Handlers - Built-in Call Handlers

While interception is a very powerful technique, it is also a bit coarse-grained. Once you set up an object for interception, each interception behavior in the pipeline will receive all interceptable member calls. Each of these behaviors must be able to receive all these member calls. If certain behaviors are designed to only work on specific members, then the behaviors themselves need to know how to target these members and leave other member calls unaffected.

Policy Injection gives you much more fine-grained control over the interception process. On one hand, it allows you to target very specific members for interception. But a policy does not need to be bound to a specific class. It can also be used to target whole families of classes (for example all service agents or view models) with a single policy. The following diagram shows how policy injection behavior works when doing instance interception:

An interception policy consists of two parts: Matching rules and call handlers. The matching rules define which call handlers should be applied in the call to specific members of the classes being intercepted, while the call handlers do the actual interception.

As you can see, policy injection is defined as an interception behavior. Therefore, in order to use policy injection on a type, you must set up either type or instance interception and have the policy injection behavior applied.

Matching Rules

Matching rules allow you specify which classes and/or members should be intercepted. You must specify at least one matching rule. All the matching rules in the policy must be satisfied in order for the call handlers to be executed.

While it is possible to create your own matching rules, there are several matching rules that ship with Unity out of the box.

Matching rule	Description
Assembly Matching Rule	Selects classes in a specified assembly.
Custom Attribute Matching Rule	Selects classes or members that have an arbitrary attribute applied.
Member Name Matching Rule	Selects class members based on the member name.
Method Signature Matching Rule	Selects class methods that have a specific signature.
Namespace Matching Rule	Selects classes based on the namespace name.
Parameter Type Matching Rule	Selects class members based on the type name of a parameter for a member of the target object.
Property Matching Rule	Selects class properties by name and accessor type.
Return Type Matching Rule	Selects class members that return an object of the specified type.
Tag Attribute Matching Rule	Selects class members that carry a Tag attribute with the specified name.
Type Matching Rule	Selects classes that are of a specified type.

By using these matching rules, you can be very flexible in determining which policies should target which classes and members:

For example, you may want to create a very specific policy that only targets a couple of methods on a class. In that case, you could specify the type matching rule to target the specific type and a member name matching rule or the method signature matching rule. The member name matching rule allows you to pass a wildcard to be a bit more flexible in specifying which names you'd like to target.

In other situations you might want to create a very flexible policy that targets an entire family of classes. For example, if you have all your service agents in a separate namespace, then you can use the namespace matching rule to set up a policy that targets all interceptable members of all the classes in that namespace.

Please refer to the Unity reference documentation on MSDN for more information about the specific matching rules.

Call Handlers

A call handler is a class that implements the ICallHandler interface. This interface has an Invoke method that is called when a member is intercepted, just as with the IInterceptionBehavior interface.

Because you have more flexibility in how you would use interception, a call handler can either be written very specifically for a particular method, or very generally, to handle any member.

Built-in Call Handlers

Enterprise Library ships with a couple of call handlers out of the box. These built-in call handlers can help you perform the following actions:

• Logging method invocation and property access
• Handling exceptions in a structured manner
• Validating parameter values
• Authorizing method and property requests
• Measuring target method performance

Next Topic | Previous Topic | Home

Last built: July 8, 2011