Francois and Erik both attended the MVP Summit that just occured in Seattle, and we had a chance to visit the ADO.NET Data Services team, where Pablo Castro gave a few talks on potential ideas for the future of that same technology.

At nVentive, we have long used a Domain-Driven Design approach to designing software. Our architectures used to rely on Entities, that would use DTOs to transfer themselves to another tier. This leads to a few interesting challenges:

• Do you share the entities ? Do you share the actual DLL?
• What if the application needs an application-model, not the entity-model?
• How do you implement the Unit Of Work pattern ? deal with derived properties and business logic?
• How do you make sure things always get revalidated on the server tier?
• When should you be modifying properties, versus calling a specialized service?
• and more...

Now we have started evaluating Command Query Seperated architectures, where data and commands are completly distinct.

The current approach is to expose the read-only data through REST (using ADO.NET Data Services). This approach is easy to use, and best of all, allows the querying of data through LINQ, which is then serialized into the URL (i.e. http://employeeSystem/Employees/$Where=firstname-eq-bob).

The current idea for the command part is to expose a second endpoint through REST (using ADO.NET Data Services) to expose the structure of the different commands. We would then use the REST syntax to create commands, edit them, and retrieve them. A runner would then execute the commands and they are queued up, altering the data.

In the coming months we will be prototyping these ideas into Umbrella, so keep on reading and if you have any thoughts, just let us know !

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.

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.

Unity is a Microsoft PnP product that is closely related to the philosophy of Enterprise Library and it’s application blocks. You can use Unity in your own applications in order to get a Dependency Inversion Container, or in less fancy words, functionality to resolve dependencies in a push matter instead of the traditional pull method.

Take for example this code:

First of all, it uses interfaces (you are using interfaces aren’t you) and the AccountingService class has one major responsibility which we don’t like… it is responsible for creating an instance of a class (DatabaseContext) that implements IDatabaseContext. The whole concept of interfaces is that we can replace them, but with this code, even if the classes implement interfaces, we are hard coding the relationship of an IDatabaseContext to the concrete class of DatabaseContext.

Let’s refactor the code to the following to extract that creation responsability:

This better code removes the creational responsibility from the AccountingService class, but just pushes up the relationship between the interface and it’s concrete to a higher layer, which is another bad thing.

Let’s introduce Unity into the equation and see what we can get:

In this example we can see that we are asking Unity’s container to “Resolve” the dependency to an AccountingService. Unity will create the object, and realize that it’s constructor depends on a IDatabaseContext. At that point it will look at it’s configuration and lookup what concrete class was specified for that particular interface.

The implementation of GetContainer goes like this:

Up till now, these are the functionalities that we have explored from Unity:

1. It can create object instances, just like the new operator does;
2. It will resolve dependencies while creating objects, for example call the constructor with valid values;
3. It allows mapping interfaces to their concrete classes, so that I can replace the concrete class in a central way;

In order for all this to work, you will have to add references to “Microsoft.Practices.ObjectBuilder2.dll” and “Microsoft.Practices.Unity”.

Unity allows for more complex configuration and dependency injection scenarios, which we will explore in part 2.

For some of the work that Erik and François have done with Microsoft's Patterns and Practices group, they have won a PnP Champion award. Find the details at msdn.

We've been looking at tools lately that could an agile team get a better view of the quality of the software they are writing. On of those is NDepend, a tool that will inspect your assemblies, determine your code's dependencies and then calculate some metrics for you to analyze. The output will typically be a report, in HTML format. Since this step can be automated, We strongly suggest that you put this into your continuous integration process because from that point, you'll be able see the metrics for your software change with time.

On a previous project, we had integrated NDepend on the daily build and at the of each iteration, we would take a few minutes to look at the reports and note a few actions to be taken during the next one. It was a great way to maintain quality and I strongly recommend you integrate it on your next project.

Now where this tool really shines, is with the VisualNDepend application. This one allows you to visualize the metrics of your software, query your software's compiled code through a SQL like language, and perform comparisons between 2 different reports.

Here are a few examples of the queries you can do in CQL:

SELECT TOP 10 METHODS WHERE CouldBePrivate

SELECT TOP 10 FIELDS WHERE CouldBePrivate

SELECT TOP 10 TYPES WHERE IsClass AND NbChildren ==0 AND !IsSealed AND !IsStatic ORDER BY NbLinesOfCode

Here are a few snapshots of the tool when run on our own Umbrella library.

This image shows Umbrella being analyzed, with the mouse pointer on one method called "Truncate". NDepend shows metrics and information all on one easy screen.

This image shows the result of the execution of 1 CQL query and where in the assembly (in blue) are located the results. Once again, bravo for NDepend: quick, concise and visual.

The author of the product Patrick Smacchia gave an interview to the Visual Studio Talk Show, a french PodCast from Montreal; if you can, we strongly suggest you listen to it and hear what the author himself has to say about this great product.

2 weeks ago, Francois and I were attending the Patterns and Practices Summit conference that was held in Quebec City.

Let me say that the presentations were really nice, and I would not hesitate to go again. This was a unique chance to have go out and meet some great minds in our industry and challenge some of nVentive's ideas with them.

This is the list of all of the sessions and the ones that particularly struck us (in no particular order) :

• Decrease Coupling and Raise Cohesion - Mario Cardinal
• Designing for Operations - David Aiken
• Empirical Evidence of Agile Methods - Grigori Melnik
• Evolving Client Architecture - Billy Hollis
• Future of patterns & practices - Don Smith
• KeyNote (Internals of the VS.NET team) - Brian Harry

We'll be integrating a few of the ideas we learned in these sessions into our teams, and we'll let blog on them as we see success out of them.