More ways to inject policies
I wanted to quickly fill you in on a couple of new additions we've made to the Policy Injection Application Block since last week's CTP that will give you more control over which objects and members your policies are applied to.
In the CTP, the only way of applying policies to members is via Matching Rules. A matching rule encapsulates logic that determines if a member should have a policy applied to it. Matching rules included with the block include ones that check for assembly, namespace, type name and signature. We also include one that looks for members with the TagAttribute applied with a particular value, eg:
[Tag("ValidateMe")]
public void Deposit([RangeValidator(typeof(Decimal), "0.0", RangeBoundaryType.Exclusive, "0.0", RangeBoundaryType.Ignore)] decimal depositAmount)
{
balance += depositAmount;
}
This matching rule is useful as it allows you to be very precise about exactly which members you want to apply certain policies to. However in some situations you may know exactly which handlers you want applied, and using external policies may not be desirable as it can obfuscate the behavior and allow post-deployment changes that you may not want. To deal with these situations, we've added support for specifying specific handlers using attributes. These attributes can be applied to members or types as follows:
[ValidationCallHandler]
public void Deposit([RangeValidator(typeof(Decimal), "0.0", RangeBoundaryType.Exclusive, "0.0", RangeBoundaryType.Ignore)] decimal depositAmount)
{
balance += depositAmount;
}
In this example, you don't need to define a policy in configuration at all. Provided the object was created or wrapped using the PolicyInjection class, any call to this method will have the Validation call handler injected between the client and the object. You could also apply multiple handlers on a type or method by specifying multiple attributes.
The other relevant post-CTP change we made in this area was the addition of the ApplyNoPoliciesAttribute. (I lobbied unsuccessfully to call this the Dont%$&#WithMeAttribute, or the CLS-compliant variation of the same). As both variants of the name suggest, applying this attribute to a type of member will indicate that you don't wany any policies or handlers applied, even if the matching rules or handler attributes would normally result in handlers being attached. This attribute can be useful in situations where any PIAB-provided surprises could adversely affect functionality or performance.
Hopefully these changes will give you the necessary flexibility in using either a broad or a fine brush to specify which cross-cutting concerns you want to apply to which objects in your applications.