Enterprise Library In-depth analysis and flexible application (1): Integration of policy injection Application block through Unity Extension implementation
The Enterprise library is one of many open source frameworks developed by Microsoft's P&p department, and the latest version has been 4.0. Since the contact with the Enterprise Library has been a long time, the frequency of use in the actual project is also very high. There are some accumulation of this, hope that through this new series and the vast number of netizens to share and exchange. This series assumes that the reader has a certain understanding of the Enterprise library, so it will not introduce the basic principles and programming models of each application block, but focus on the Enterprise Library's deep realization principle, The application of design patterns, effective expansion and best practices.
What we are discussing today is how to achieve unity and PIAB integration through custom unitycontainerextension, and we assume that the reader has been to the Unity Application Block and policy injection Application Block already has a certain understanding.
1. Create Policyinjectionstrategy
We know that policy injection Application block is based on the remoting principle of implementing AOP through method interception (while another common approach is based on IL injection). To make an application work on the Callhandler of the target object, you need to create the object by Policyinjecctor (remoting policyinjection by default). And the way to achieve unity and PIAB integration is to let unity container use to create objects.
Unity is built on ObjectBuilder, and ObjectBuilder is the cornerstone of the entire Enterprise Library and p&p other open source frameworks (such as Smart Client Software Factory). ObjectBuilder, as the name suggests, is the component that makes object creation. The way ObjectBuilder creates objects is policy-based (strategy based object creation) by applying different policies to the different stages of object creation (or release of recycling), and from providing a powerful, A framework for extremely extended object creation. And to achieve our goal, we first need to create a custom builderstrategy:policyinjectionstrategy.
Namespace Artech.policyinjectionintegratedinunity
{
public class Policyinjectionstrategy:enterpriselibrarybuilderstrategy
{
public override void Prebuildup (Ibuildercontext context)
{
Base. Prebuildup (context);
if (context. Policies.get<ipolicyinjectionpolicy> (context. Buildkey) = = null)
{
Context. Policies.set<ipolicyinjectionpolicy> (New Policyinjectionpolicy (TRUE), context. Buildkey);
}
}
public override void Postbuildup (Ibuildercontext context)
{
Base. Postbuildup (context);
Ipolicyinjectionpolicy Policy = context. Policies.get<ipolicyinjectionpolicy> (context. Buildkey);
if (policy!= null) && policy. Applypolicies)
{
Policy. Setpolicyconfigurationsource (Enterpriselibrarybuilderstrategy.getconfigurationsource (context));
Context. Existing = policy. Applyproxy (context. Existing, Buildkey.gettype (context. Originalbuildkey));
}
}
}
}
Above is the definition of the whole policyinjectionstrategy. Add Policyinjectionpolicy to the policy list of Buildercontext by Prebuildup before the object is created (Buildercontext Provides context information for the creation and lifecycle management of an entire object. In Postbuildup, the Policyinjectionpolicy is removed from the Buildercontext, and the Applyproxy method is invoked to encapsulate the object created by Policyinjecctor, then the encapsulated object is invoked. Our policy injection Callhandler can play its part.
Note: The Policyinjectionpolicy is set in the Microsoft.Practices.EnterpriseLibrary.PolicyInjection DLL to implement the Microsoft.Practices.EnterpriseLibrary.PolicyInjection.ObjectBuilder.IPolicyInjectionPolicy and Microsoft.Practices.ObjectBuilder2.IBuilderPolicy. The Applyproxy method is actually called the Policyinjecctor wrap method.