The founders of nVentive, Erik Renaud and Francois Tanguay have both been awarded a MVP award. It is an honor to be recognized by Microsoft in this way and nVentive will continue to implicate itself in the community, following it's mission to perform coaching and guidance for agile software development using .net technologies.

nVentive's Erik Renaud will be speaking at the January 28th @Lunch meeting on the subject of Dependency Inversion using Unity.

Part 1 and part 2 of this series were devoted to Unity, and part 3 introduced interception. Let’s examine Unity’s interception mechanism in more details.

Let’s look at the GetContainer method once again:

From this code, you can see a few concepts being introduced.

The first is the configuration of an interceptor, which defines how interception is to be made for the specified class. In this case, we are using the VirtualMethodInterceptor which creates a new class, on the fly, which derives from the AccountingService and overrides anything virtual as place holders for executing the policies (more on policies later).

The current interceptors are:

1. VirtualMethodInterceptor, which can intercept virtual calls by deriving a a class from the intercepted class.
2. InterfaceInterceptor, which can intercept any call on a given a interface, by creating a class that implements the specified interface and decorates the concrete type.
3. TransparentProxyInterceptor, which can intercept anything deriving from MarshalByRefObject or an interface and reuses the .net technology for remoting. Out of the three, this is the slowest interceptor but also the one that is the most flexible.

The other part of configuring is the creation of a policy. A policy is basically something that has a name (RuleDrivenPolicy), knows how to identify things it needs to intercept (IMatchingRule) and calls handlers (ICallHandler).

Out of the box, Unity comes with many matching rules but no call handlers. If you are using Enteprise Libary’s PIAB, you will find that PIAB implements may call handlers for invoking the security, logging, exception management…

The following code will get you on your way to creating your own call handlers:

Note that there is always a AttributeDrivenPolicy present in the container, which uses attributes for matching rules and call handlers. All you have to do is create attributes that derive from HandlerAttribute and off you go.

In part 2, we saw the we could also configure the container through xml configuration files. The same is true for interception and GetContainer would look like this:

The exact same syntax as for configuring Unity, isn’t that great ! The backing XML though is another thing, here is an example:

Now how’s that for XML !!!

We hope that these posts will reassure you and help you integrate Unity into your software. Unity is quite powerful and we have only touched the surface. Feel free to write to use to get more information.

After presenting at Microsoft TechDays the “BlackBelt WPF DataBinding Session”, we received a very interesting question from one of the attendees:

If there are validation rules associated to a binding declared in XAML and validation fails due to invalid data, the value in the target (“onscreen value”) will not be in sync with the value in the source (your business object).

In the end, the folllowing screen shot shows what we want :

1. The ErrorTemplate is active, because a validation error occured;
2. The tooltip shows the range of valid values and the invalid value that was entered;
3. The textbox shows the currently binded value, and not the actual invalid value that the user entered.

By default, the text box would show the invalid value, and would be out of sync with the binded object.

This is what we came up with to change that default behavior: when the validator fails, invoke the binding mechanism as to update the target (onscreen value) with the current value in the source (business object).

Here is the recipe:

1. Implement INotifyPropertyChanged on your business object.
2. Create the IRaiseNotifyPropertyChanged:
   

       1     public interface IRaiseNotifyPropertyChanged

       2     {

       3         void Raise(string PropertyName);

       4     }

3. Implement IRaiseNotifyPropertyChanged on your business object as follows:
   

       1         public void Raise(string PropertyName)

       2         {

       3             if (PropertyChanged != null)

       4             {

       5                 PropertyChanged(this, new PropertyChangedEventArgs(PropertyName));

       6             }

       7         }

4. Add these two properties to the class that implements your validation rule (derives from ValidationRule):
   

       1         public string PropertyName { get; set; }

       2         public object Target { get; set; }

5. Modify the Validate method like this:
   

       1             if ((age < Min) || (age > Max))

       2             {

       3                 if (Target is IRaiseNotifyPropertyChanged)

       4                 {

       5                     IRaiseNotifyPropertyChanged t = Target as IRaiseNotifyPropertyChanged;

       6                     t.Raise(PropertyName);

       7                 }

       8 

       9                 return new ValidationResult(false,

      10                   "Please enter an age in the range: " + Min + " - " + Max + ". You entered : " + value.ToString());

      11             }

      12             else

      13             {

      14                 return ValidationResult.ValidResult;

      15             }

6. Use the validation rule like this in your XAML:
   <c:agerangerule target="{Binding}" propertyname="Age" max="130" min="21">

We hope that this will be useful in your WPF adventures !

In part 1 and part 2, we briefly explored what was Unity. In this part, we’ll introduce the subject of interception.

In releases prior to 4.1 of Enterprise Library, interception was something provided by the “Policy Injection Application Block”. One of the big moves for 4.1 was to refactor the functionality into Unity, and modify PIAB to be a facade (easier to use interface) over Unity.

But the question remains, what is interception. Interception relates to a programming technique called AOP (Aspect Oriented Programming) and deals with things that are mostly non-functional (logging, exception handling, security, caching…). This said, you would use interception to perform security checks (for example) in a transparent way while calling a target method on a target object.

From this example, you see that we are resolving the AccountingService class through the container, and then calling the Deposit method. Let’s see how we implemented GetContainer() to account for interception.

From this example, you cann see that we are asking Unity to intercept AccountService types using the VirutalMethodInterceptor, and to define a policy, that will be applied to types of type AccountingService who will invoke the SecurityCallHandler. The SecurityCallHandler is defined as such:

The call handler is what performs you non-functional code. This is where you would put your logging, validation, security, caching code, which would transparently wrap the object being intercepted.

More on the possibilities in part 4.

In part 1, we explored that basic functionality that Unity has to offer. In this post, we’ll explore a few more things in order to make Unity truly usable.

Back to dependency injection, we saw in part 1 that Unity will call the constructor with valid arguments. This is called constructor injection. There are two other types of injections, namely property and method that are resolved at creation time. Here are the examples.

Property injection:

And method injection:

Of course, since a class can have more than one constructors, sometimes we need to help Unity by explicitly saying which one to use. Here is an example:

Now for the other point that we’d like to cover: configuration. Unity’s approach to configuration is quite different that the one employed in Enterprise Library. API support is included in Unity’s core library and support for externalizing the configuration to XML configuration files is provided by the “Microsoft.Practices.Unity.Configuration.dll” assembly (and let’s not forget the “System.Configuration.dll” assembly). The technique used simply reuses the configuration API, which opens the door to home grown configuration plugins (i.e. from a database).

These are the things that you can configure in Unity:

1. How to perform dependency injection (without the usage of attributes);
2. The mapping of interfaces to their concrete classes;
3. “Named resolves”, or the ability to ask the container to resolve something which is explicitly named;
4. Lifetime managers, or how to control the lifetime of objects created by the container (The singleton pattern could be implemented by configuring the container with ContainerControlledLifetimeManager);
5. Support for resolving arrays;
6. And more…

Here is an example on how to consume external configuration:

Of course, this will assume that a configuration section named “unity” exists in your application configuration file, that should look like this:

These posts are not meant to explore every single feature present in Unity, but rather to get your started on the core concepts. Unity ships with plenty of documentation that will allow you to grasp what else can be done.

Coming up, part 3, which will introduce the subject of interception.