.NET

CMAP Code Camp Wrap Up - Dependency Injection and IoC Containers

Matthew Podwysocki — Mon, 14 Apr 2008 04:45:14 GMT

I really enjoyed speaking at this past weekend's CMAP Code Camp. I hope you all enjoyed my presentation on "Loosen Your Dependencies with Dependency Injection and Inversion of Control Containers". It was a great discussion to have with everyone and I like to learn there as much as I teach.

I also enjoyed teaming up with Scott Allen on his "A Gentle Introduction to Mocking" where we talked about mocks versus stubs, test pattens and mock frameworks such as Rhino Mocks and Moq. Hopefully we'll be doing some more ping-pong sessions in the future.

Once again, I'd like to plug my DC ALT.NET group that I run. Our next meeting is scheduled for April 23rd and the topic will be Continuous Integration with Jay Flowers. We'll announce the location shortly for our group. You can go ahead and sign up for our mailing list here.

Anyhow, here are some resources that can help point you in the right direction. This includes articles, blogs and such that I find will be useful in your journey to better understand these things:

My presentation materials have just been uploaded to my SkyDrive. The PowerPoint presentation can be found here and the code samples can be found here.

If you note, I my code uses the following products in order to get it to run:

Feedback is always appreciated.

Unity Community Contributions and Interception

Matthew Podwysocki — Sat, 12 Apr 2008 00:35:05 GMT

Now that Unity has been released into the wild, there has definitely been a bit of interest swirling around it. One of my key wants for a good IoC container is basic interception capabilities. My criteria for evaluating a container usually comes down to the following:

Configurability (XML, DSL, Code)
Dependency Resolution, usually opinionated
Lifetime Management (Per Thread, Pooled, Singleton, Transient, etc)
Extensibility for Interception

So, I realized that Unity was missing some of these things in the first go around. Since Unity was built on top of ObjectBuilder2, a next generation version of the often maligned ObjectBuilder which also included some sample DI containers and a flexible interception model. Today's post will cover that and a bit more. I realize that I still am working on a post of AOP in the Enterprise and Spring.NET which is coming soon.

Where We Are

But, before we begin today, let's see what we've already covered in the past:

Unity 1.0 Released into the Wild
Unity 1.0 released and available on MSDN. Unfortunately, registration is required...
IoC and Unity - Configuration Changes for the Better
Covers the configuration changes to allow for better parameterization for constructors
IoC and Unity - The Basics and Interception
Talking about the basics of IoC containers and the interception models
IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block

Now that we've look at the history of this series, let's go ahead and get started.

Unity Contributions

Since Unity was released last Friday, there has been a community effort much like the ASP.NET MVC Contributions, MVCContrib, called Unity Community Contributions. This project is intended to fill in the gaps where the community feels that Unity can be extended, much like most other IoC containers. As I stated above, one of those crucial things that I thought was missing was taking the ObjectBuilder2 Interception model and applying it towards Unity. I wasn't interested as much in the Policy Injection Application Block, although nice, is a bit heavyweight for the basic operations I would like. Instead, the OB2 would suffice for most things that I'd want with a container. So, that led me to another topic...

ObjectBuilder2 Interception == Unity Interception?

Since I was particularly motivated to see the OB2 Interception model pushed into Unity, I decided to give it a go myself. For the most part, I was successful in a way, but I wasn't using the right extensibility model. From that point, I got in contact with Scott Densmore, a PM within the Patterns & Practices group and one of the authors of ObjectBuilder2 along with Brad Wilson. From that point, he was able to take the original OB2 Interception model and fit it nicely into the Unity extensibility model. The code is now available on the Unity Community Contributions and you can find those commits by Scott here.

So, let's take a look at what it entails. As I tell most people, you learn the most about the software with good unit, I mean behavioral tests where I can really grok the intent of the code much better than most documentation. I encourage most people to do the same. I'd rather stay away from those projects that don't have tests to back up their work.

Like I said before, ObjectBuilder2 had several ways of intercepting calls. There are several interception strategies worth mentioning:

Virtual Method interception
Interface Method interception
.NET Remoting interception (MarshalByRefObject)

From that, you have two ways of registering your interest for interception:

Intercept via code
Intercept via attributes

Now that we've laid down the basics, let's take a look at some of the unit tests. You'll notice that xUnit.net was used for the unit tests. Yes, I know, I've mentioned it a few times lately. Anyhow, let's look first at virtual method interception.

Before we get started on that, in order to perform interception, we need to implement the IInterceptionHandler interface. For the unit tests, this will be used to record the various actions that happened during the interception process. But you can imagine it to do any number of things such as logging, transaction management, security and so on. Any of those cross cutting concerns, really.

    public delegate IMethodReturn InovkeHandlerDelegate(IMethodInvocation call,

                                                        GetNextHandlerDelegate getNext);

    public delegate InovkeHandlerDelegate GetNextHandlerDelegate();

    public interface IInterceptionHandler

     {

        IMethodReturn Invoke(IMethodInvocation call,

                             GetNextHandlerDelegate getNext);

     }

 } 

   public class RecordingHandler : IInterceptionHandler

    {

        readonly string message;

        [InjectionConstructor]

        public RecordingHandler()

        {

            message = "";

        }

        public RecordingHandler(string message)

        {

            this.message = string.Format(" ({0})", message);

        }

        public IMethodReturn Invoke(IMethodInvocation call,

                                    GetNextHandlerDelegate getNext)

        {

            Recorder.Records.Add("Before Method" + message);

            IMethodReturn result = getNext().Invoke(call, getNext);

            Recorder.Records.Add("After Method" + message);

            return result;

        }

    }

We have the ability through the Invoke method to do things before the method as well as after. Should we need to modify values before the method is called, we can go ahead and do so. Now that we looked at that, let's get to some unit tests. First off, let's look at interception through just code. I like this approach as opposed to attributes due to not cluttering the domain model and making it more configurable at run time.

            [Fact]

            public void InterceptViaCode()

            {

                Recorder.Records.Clear();

                IUnityContainer container = new UnityContainer();

                container.AddNewExtension<InterceptionExtension>();

               container.Configure<IInterceptionConfiguration>().InterceptVirtual<SpyVirtual>
                   (typeof(SpyVirtual).GetMethod("InterceptedMethod"), new RecordingHandler());

                SpyVirtual obj = container.Resolve<SpyVirtual>();

                obj.InterceptedMethod();

                obj.NonInterceptedMethod();

                Assert.Equal(4, Recorder.Records.Count);

                Assert.Equal("Before Method", Recorder.Records[0]);

                Assert.Equal("In Method", Recorder.Records[1]);

                Assert.Equal("After Method", Recorder.Records[2]);

                Assert.Equal("In Non-Intercepted Method", Recorder.Records[3]);

            }

public classSpyVirtual

            {
public virtual void InterceptedMethod()

                {
Recorder.Records.Add("In Method");

                }

public void NonInterceptedMethod()

                {
Recorder.Records.Add("In Non-Intercepted Method");

                }

public virtual void ThrowsException()

                {
Recorder.Records.Add("In Method");
throw new Exception("This is my exception!");

                }

            }

As you see above, we can simply register our interest through the registration of the InterceptionExtension and then set up the configuration through the IInterceptionConfiguration. From that point, we then say which kind of interception we want whether it be virtual, remoting or interfaces. We specify the method we want to intercept by name.

You can also do the interception through the use of attributes. From this point, we need to decorate our methods with the attribute and the particular interception handler we want to use. We need to be aware of which interception strategy we're using as well when we decorate our classes. You can intercept methods as well as property accessors by decorating the get or set. Below is a simple example of a virtual interceptor registration.

             public class SpyVirtualAttributes

            {

                [VirtualIntercept(typeof(RecordingHandler))]

                public virtual void InterceptedMethod()

                {

                    Recorder.Records.Add("In Method");

                }

            }

I'm not going to post all of the tests, but I want to give you an idea of the power of this. It's still early in the process and there is some cleanup still going on. But, I encourage you to pick up the source, read it, grok it, give it a try and give feedback.

Conclusion

As you can see, the extensibility model of Unity works in that we can add interception to Unity. So, we can start thinking about moving our cross cutting concerns to these layers should we so choose if Unity is your container of choice. There are plenty of containers out there to choose from, so it's best to give them all a try and pick one based upon features, programming style, and heck, maybe even licensing. I'll be showing some of this stuff off tomorrow at the CMAP Code Camp, so if you'll be at my 1PM session, be prepared. Until next time...

Unity 1.0 Released into the Wild

Matthew Podwysocki — Mon, 07 Apr 2008 05:40:55 GMT

As Chris Tavares mentioned in his blog, Unity 1.0 has been released a couple of days earlier than the April 7th release date mentioned by Grigori Melnik earlier. Scott Densmore also announced this as well as working on porting the inteception from ObjectBuilder2 which I talked about earlier in some of my Unity and IoC containers posts. Looking forward to that post as we've shared some emails on the subject.

Would You Like To Know More?

For those looking for my posts on the matter, I've covered it quite extensively with the comparison to other IoC containers as well as IoC containers in general:

IoC and Unity - Configuration Changes for the Better
Covers the latest configuration changes to allow for better constructor injection
IoC and Unity - The Basics and Inteception
Covers the basics of an IoC container and inteception techniques
IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block

Anyhow, if interesting in more Unity content, check out David Hayden's Unity IoC and MVC screencast as well as others on the subject here.

Speaking of which, I'm going to be a busy man indeed with my upcoming speaking schedule on IoC containers, not necessarily Unity in particular, but all of them, the background and decoupling your applications. Here is the complete schedule for this month:

RockNUG - April 9th
CMAP Code Camp - April 12th
CMAP Architecture SIG - April 15th

I hope to contribute some at ALT.NET Open Spaces, Seattle as well on a few subjects and DC ALT.NET on April 23rd as well. Should be a great time and feedback is always appreciated.

XUnit.net RC2 Released

Matthew Podwysocki — Tue, 01 Apr 2008 00:31:06 GMT

UPDATE: More posts on the subject

UPDATE: xUnit.NET RC2 New Drop includes ASP.NET MVC support and better GUI runner. Details here.
UPDATE: Added Static Methods mention and F# - Thanks to DevHawk!

I've been a big fan of such testing frameworks as NUnit and MbUnit, but recently I've found myself getting pulled more towards xUnit.net at least to play around with for any of my code samples that I write for this blog and on my own time. I'm not really a fan of MSTest and many I think would agree about its deficiencies. I won't go as far as say Jay Flowers and wear the shirt though...

Another Release?

Recently, Brad Wilson and Jim Newkirk recently announced the release of xUnit.net RC2 on CodePlex. I'd encourage you download the latest bits here. For those wondering what changes happened between RC1 and RC2, Brad has a good writeup on his blog here. What's interesting about this is the removal of the Assert class methods which take a user defined message should it fail. I was never really a fan of those in the first place though.

Another interesting added features was the IUserFixture<T> which allows you to have a startup and teardown for your fixtures in a separate class and therefore reusable, unlike the current way of using no parameter constructors as your startup and the IDisposable.Dispose for your teardown. See the tests in the FixtureExample for details. But here's a snipped version of that code:

    public class DatabaseFixture : IDisposable
    {
        SqlConnection connection;
        int fooUserID;
 
        public DatabaseFixture()
        {
            string connectionString = ConfigurationManager.ConnectionStrings["DatabaseFixture"].ConnectionString;
            connection = new SqlConnection(connectionString);
            connection.Open();
            string sql = @"INSERT INTO Users VALUES ('foo', 'bar'); SELECT SCOPE_IDENTITY();";
 
            using (SqlCommand cmd = new SqlCommand(sql, connection))
                fooUserID = Convert.ToInt32(cmd.ExecuteScalar());
        }
 
        public SqlConnection Connection
        {
            get { return connection; }
        }
 
        public int FooUserID
        {
            get { return fooUserID; }
        }
 
        public void Dispose()
        {
            string sql = @"DELETE FROM Users WHERE ID = @id;";
 
            using (SqlCommand cmd = new SqlCommand(sql, connection))
            {
                cmd.Parameters.AddWithValue("@id", fooUserID);
                cmd.ExecuteNonQuery();
            }
 
            connection.Close();
        }
    }

What the above code allows us to do is to define a class that holds the data from the initialization of the first test, to the cleanup after the last test. Our state is therefore maintained in a reusable manner. As you will note, the startup logic resides in the default no parameter constructor and all teardown logic is in the IDisposable.Dispose method.

    public class FixtureTests : IUseFixture<DatabaseFixture>
    {
        DatabaseFixture database;
 
        public void SetFixture(DatabaseFixture data)
        {
            database = data;
        }
   
        [Fact]
        public void FooUserWasInserted()
        {
            string sql = "SELECT COUNT(*) FROM Users WHERE ID = @id;";
 
            using (SqlCommand cmd = new SqlCommand(sql, database.Connection))
            {
                cmd.Parameters.AddWithValue("@id", database.FooUserID);
                int rowCount = Convert.ToInt32(cmd.ExecuteScalar());
                Assert.Equal(1, rowCount);
            }
        }
    }

Then we can go ahead with our tests, while using the SqlConnection as defined on our DatabaseFixture. After we're done with our test, it goes ahead and calls Dispose on the fixture. I tend to like this approach and it's definitely growing on me.

Why xUnit.net?

For those new to xUnit.net, there are some decent links to help you along. Some of the more interesting ones can be found here:

But, why am I interested in it? Well, let's just say that I think it tackles things in a slightly different manner. I think one of the key pieces that I really like is the Assert.Throws instead of the clumsy ExpectedExceptionAttribute which you must clutter your tests with on the top. I would rather assert that such a thing happened programmatically, so that I may analyze the exception. I can also specify which line I expect during my test will throw the exception, instead of taking on blind faith that my test threw an exception. It may be of the right type, but that may not have been the one you wanted, thus giving a false sense of security.

To use this, just simply use the Assert.Throws<TException>(Assert.ThrowsDelegate) which I've found to be very helpful. Let's look at a quick test of that being used.

    [Fact]
    public void PopEmptyStack()
    {
        Stack<string> stack = new Stack<string>();
        Assert.Throws<InvalidOperationException>(() => stack.Pop());
    }

As you can see, we're pretty explicit about what line will throw the exception, and that's really the key to this scenario. There are a good number of samples provided on the releases page that you should check out. As always with most products that I talk about, I highly recommend reading the tests to really fully understand what's going on underneath the covers. Not only does it help you understand the intent of the program, but you can learn about good coding techniques, design patterns, testing patterns and so on.

Another point that xUnit.net separates itself from the pack is the ability to decorate static methods as facts. This frees you from having to create an instance of your test class in order to call them. Harry Pierson, aka DevHawk, demonstrates its use with regards to F# and testing the parse buffer here. It definitely opened my eyes and a few more avenues as I pursue more F# related work items in the future. Here's just a quick and dirty sample of showing how you can use xUnit.net with F# quite easily, just as Harry's post did.

#light

#R @"E:\Tools\xunit-build-1223-samples\Samples\xunit\xunit.dll" 

open System

open System.Collections.Generic

open Xunit

type Stack<'t> = class

  val elements : LinkedList<'t>

  new() = { elements = new LinkedList<'t>() }

  member x.IsEmpty

    with get() = x.elements.Count = 0

  member x.Push element =

    x.elements.AddFirst(element:'t)

  member x.Top

    with get() =

      if x.elements.Count = 0 then

        raise (InvalidOperationException("cannot top an empty stack"))

      x.elements.First.Value

  member x.Pop = 

    let top = x.Top

    x.elements.RemoveFirst()

    top

end

[<Fact>]   

let NoElementsShouldBeEmpty () =

  let stack = new Stack<string>()

  Assert.True(stack.IsEmpty)

If you notice, the FactAttribute is placed on a static method called NoElementsShouldBeEmpty and sure enough it works like a champ through xUnit.net. I like this approach instead of the pomp and circumstance required for creating classes as shown above with my Stack class. Note the use of the empty parans which forces it to be a void method with no values passed either. But if you run it through the xunit.console sure enough it succeeds like a champ.

What are we missing though? Well, I'm in favor of having a standalone GUI Test Runner much like NUnit and MbUnit have. In fact, Brad has started this and you can get these features from the latest commits here. Mind you I haven't gotten it to work just right yet, but it's a work in progress.

Conclusion

There is a lot to like about xUnit.net and takes a lot of lessons learned from the use of NUnit, MbUnit and others and I think they're doing a good job incorporating issues. This project isn't as active as MbUnit and NUnit, but it's definitely one to keep an eye on. Recent releases of NUnit and Gallio Automation Platform will probably be also covered in the short while as well as they have a lot to offer. Until next time...

Understanding AOP in .NET

Matthew Podwysocki — Sat, 29 Mar 2008 00:45:16 GMT

In my previous posts I have talked a bit about Inversion of Control (IoC) containers with respect to Interception and Aspect Oriented Programming (AOP). It's not only important to understand the uses and strategies for implementing your solutions using it, but also how interception and AOP works deep down in .NET. Instead of a long, drawn out post, I think I'll just include some articles and posts that do a very good job of explaining some of the ideas behind it.

Articles and Posts

I think it'd be good if we just start out with some basic MSDN articles and such regarding AOP and interception. Some of them may be older but the concepts will still apply to this day:

7 Approaches for AOP in .NET
Ayende covers a few ways of doing AOP in .NET using existing frameworks
Decouple Components by Injecting Custom Services into Your Object's Interception Chain
Juval Lowy, in the March 2003 MSDN magazine, writes about using contexts for an object's execution scope and intercepting calls to and from that object.
Aspect Oriented Programming (September 2005 Technical article)
Matthew Deiters describes aspect oriented programming and covers joinpoints, pointcuts, advice and mixins with regards to a simple example using VB.NET.
AOP: Apsect Oriented Programming Enables Better Code Encapsulation and Reuse
Dharma Shukla, Simon Fell and Chris Sells write in the March 2002 MSDN Magazine with regards to the history to COM and AOP and then relate how it works in .NET. Rather dated article but the foundations still apply.
AOP using System.Reflection.Emit
Roberto Loreto writes on CodeProject how to intercept method calls of an external type and generating method proxies by using Intermediate Language (IL) injection.

Just Read the Code

There are many AOP frameworks out there in the wild right now for .NET. To understand them pretty well, it's best if you just crack open the code and follow the unit tests. Most of these are no longer active. Let's cover some of the AOP frameworks out there:

PostSharp
NKalore (No longer active)
Gripper LOOM.NET
Rapier LOOM.NET
AOP.NET (No longer active)
Aspect# (No longer active)
AspectDNG

Many containers also implement AOP through the IoC container such as:

Conclusion

For those willing and able to go ahead and learn about AOP, it's actually quite interesting. it's also quite a challenge especially when dealing with IL emitting. Go ahead and look at the source code and samples and give some of it a try. Next time we pick up, I'll be talking about AOP in the Enterprise and Spring.NET. Until next time...

Looking at DSLs in .NET

Matthew Podwysocki — Wed, 19 Mar 2008 00:43:44 GMT

As I've mentioned in recent posts such as here, here and here, I've been very interested in Domain Specific Languages (DSLs), especially with regards to F# and the DLR as well. I recently re-listened to Software Engineering Radio Episode 52 with Obie Fernandez discussing DSLs in Ruby. One of the things that attracted me to Ruby for this was the flexibility of the syntax for closures, mixins, etc. Anyhow, it's a good listen and if you're new to the subject, you should give it a go. Also, there is a slide deck of DSLs in Ruby which accompanies this episode which can be found here.

So, of course this gets me excited about the possibilities of seeing such things in IronRuby. After seeing John Lam's presentations at MIX08 and listening to him on various podcasts, I'm excited that they are making such progress and hopefully get it into our hands soon.

But, before we get too deep into things, I just want to take a step back and look quickly at what DSLs are.

Internal and External DSLs?

So, what are DSLs? Well, to put it succinctly, it's a small language that's used for a very narrow task. You can think of these as languages specific to a domain such as medical claims processing, stock trading and so on that only have meaning there. These languages mean very little outside their problem domain and probably wouldn't make sense to anyone outside. I'm very well aware of such things as I've worked in the medical claims processing industry and their terms, calculations and so on are very specific and to solve the problem well, it's best to suit the language best for expressing solutions.

Martin Fowler wrote an article entitled "Language Workbenches: The Killer-App For Domain Specific Languages?" in which he talks about the history of DSLs especially in the Lisp world, but until now really haven't caught on. Martin argues that XML structures such as configuration files, and so on qualify for that status, due to the fact that it is readable by a human and probably a domain expert as well. But Lisp is well know for the Lex/Yacc parsing and expression trees and so on.

Now the real interesting part comes in when we talk about internal versus external DSLs...

External DSLs, quite simply, are those languages that are not in the same language as the main application itself. This means that I could be free to write any free-form code I wish in order to suit my domain specific need. This means that you need to write parsers and then ultimately would need to have a translation boundary between your DSL and your application. This is where I think something like the Dynamic Language Runtime (DLR) could come into play. What I mean by that is that if you write your language parser for the DLR, and I'll get into that shortly. There is a bit of overhead with this of course, plus a good debugger and IDE, but with time and patience things like this can be overcome. Extending such things as #Develop to encompass those pieces is feasible.

Internal DSLs, on the other hand, are the little languages you can create inside your current language of choice. Now languages such as Lisp, Ruby, Scala, Boo, and F# seem a bit more suited for these than the mainstream languages of C++, C# and Java. Of course one of the bigger obstacles is the pesky curly brace which Ruby allows you to discard. F# doesn't have a concept of this either, and instead the indentation scopes the values and functions and so on. Martin has an interesting DSL written in Java that's interesting and could be better applied in different languages.

Thinking About The DLR

As I said before, I'm pretty excited about the DLR and the flexibility it can give me as a software engineer looking for new and better ways to solve my customer's problems. Not only that, but I'm a language geek at heart, what can I say? I've posted several items on building on the DLR in the context of external DSLs as well as writing custom compilers for .NET. Projects such as Irony also appeal to me in that way.

If you want to play around with the DLR, you can get it in one of two places, the IronPython download on CodePlex or on RubyForge with the IronRuby project.

Martin Maly, a member of the DLR team has continued his posts about Building on the DLR. He took some time off to work on some DLR related issues and now is back with some more posts. Let's continue where we left off last time:

Answering Some Questions
Martin talks about Static and Dynamic Nodes on DLR Trees
Variations on Trees
Martin talks about DLR trees and LINQ Expression trees
More questions
Martin talks about implementing a Print method that acts differently per incoming data type
Extension Methods
Martin talks about adding extension methods to the ToyScript sample

So, as you can see, the DLR has progressed quite a bit, and maybe creating that DSL using the DLR isn't so far off after all. That is of course if you understand expression trees and so on. But, the great part about the DLR is that they ship the ToyScript source code with this for you to play with and learn from when you download it.

DSLs In Boo?

Oren Eini, aka Ayende, has been working on a book about DSLs called "Building Domain Specific Languages in Boo". Recently, he posted about some sample chapters now available online with the source code. I highly recommend that you at least give it a look. You now have access to the Early Access Edition, and of course you can buy it online. It'll be interesting to see Ayende at ALT.NET Open Spaces, Seattle to see if he wants to cover more of this stuff.

If you're not familiar with Boo, it's one of Ayende's preferred languages. Such tools as Binsor (The DSL for Windsor) were written in Boo. If you're not familiar with the language, it has very similar syntax to Python and formats very nicely. This easily fits Martin Fowler's category as an external DSL. #Develop has some support for Boo to make it a first class language in the .NET family. It also ships as part of the Castle Project. Anyways, a quick sample of Binsor makes it look like a nice DSL for type registration in Castle Windsor in Boo Script:

import Rhino.Commons
logger = Component("console_logger", ILogger, ConsoleLogger)

Check out the first chapter of Ayende's book which is available free online and explore it yourself for DSLs.

DSLs in F#?

Another part that had me intrigued was the possibilities of not only Boo to do this, but F# as well. Robert Pickering covers this in his book, Foundations of F#. If you pay attention to Chapter 11, he covers DSLs in F# and gives a few examples of how you can do so. To me, it's pretty powerful because you have a lot of the built-in features of a functional programming language such as lists, pattern matching and so on. Such examples as given are such things as the arguments parser in F# that is described in the Arg class in Microsoft.FSharp.Compatibility.OCaml namespace. This allows you to parse well known data structures as first class citizens. Martin Fowler also gave such an example from the article I quoted from above. F# lends itself quite well to DSLs in regard to support for lambda expressions.

Don Syme also covers these topics in his book Expert F# in Chapter 9. This covers more language oriented programming techniques, but you can scan some information about building DSLs in F#. Some interesting parts of this come down to Active Patterns which I covered partially yesterday. In the coming weeks, I hope to post some of my forays into this, taking some samples from the Ruby community and applying some of the same functionality in F#.

Conclusion

There is still much yet to be covered in this topic of DSLs in .NET languages. We can go on and on with regards to internal and external DSLs and argue about which language is suited for each. But in the coming weeks, I hope to take some samples and show how they can apply cleanly in F#, and probably run into some language problems where it might not be the best fit. But, that's the fun part about it.

Videos and Interviews from MIX08

Matthew Podwysocki — Tue, 11 Mar 2008 00:21:46 GMT

Well, I've had the urge to find all the videos I could and watch them to find out all the goodies I missed while not at MIX08. If you missed any of the main sessions, you can find out more about them here. Note that there are 88 sessions recorded here, so it's a lot of good viewing material.

Best of all are Scott Hanselman's MVC Videos can be seen here. He also covers the MVC Mock Helpers which better allow for unit tests using various Mock frameworks including Rhino Mocks, TypeMock.NET and Moq.

Dave Laribee was great on Twitter to make sure we were all kept up to date with all the good things that were happening. Brendan Tompkins supplied Dave with a video phone so that he could capture impromptu videos and such. But, best of all they were broadcasted live. He was able to talk to guys like Rob Conery, Phil Haack, Steve Harman, Miguel, John Lam, Scott Hanselman and Josh Holmes. Very cool stuff! They were pretty good and entertaining, although the video wasn't always superb and sometimes you needed motion sickness pills. But, the sessions of note are:

More of them can be found here. And it's enough to make Phil think that he has enough of a fidgeting problem... Well, enjoy!

IoC Container, Unity and Breaking Changes Galore

Matthew Podwysocki — Fri, 07 Mar 2008 08:13:25 GMT

Update: IoC and Unity - The Basics and Interception

As Grigori Melnik noted on my blog previously as well as his own, there was a brand new drop of the Unity Application Block as of March 4th. This by far was a huge update with a lot of breaking changes. That teaches me to use a CTP of any product and blog about it actively as it compares to other Inversion of Control (IoC) containers. Glad I didn't do a lot on ASP.NET MVC just yet but I have a few good projects going on the side with that now.

Where I've Been Before

As noted here before, I've been spending some time actively comparing the Unity Application Block to other IoC containers and what each offers. Let's get caught up to my previous posts:

I'm probably going to change the code on each one just so that you all don't get angry about code from me not working, so stay tuned, it will get done. But, keep in mind, it is still CTP, and I'd rather concentrate on the concepts as well.

What's Changed

As you may notice if you did any of the code snippets I published, they sure as heck don't build anymore. So, let's enumerate the changes made so far:

UnityContainer method Register<TFrom, TTo>() becomes RegisterType<TFrom, TTo>()
UnityContainer method Get<T>() becomes Resolve<T>
UnityContainer method SetSingleton<T> removed
UnityContainer method RegisterType<TFrom, TTo> accepts a LifetimeManager to create Singletons
Added ContainerControlledLifetimeManager and ExternallyControlledLifetimeManager
Removed DependencyAttribute NotPresentBehavior property and enum
Added UnityContainer CreateChildContainer method to create child sandboxes
Reversed the parameters for UnityContainer method RegisterInstance<T>(value, key) to RegisterInstance<T>(key, value)

As you can see, some of these changes can be seen as quite annoying especially if I were to have a method such as the following and I can't find the error until I sit and read the code through and through:

Old:

IUnityContainer container = new UnityContainer();
container
    .RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
    .RegisterInstance<string>("administrator@example.com", "defaultFromAddress");

And sure enough, it blew up due to the fact that it seemed just fine because it was RegisterInstance<string>(string, string) and instead I had to change it to this to get it to work.

New:

IUnityContainer container = new UnityContainer();
container
    .RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
    .RegisterInstance<string>("defaultFromAddress", "administrator@example.com");

Nothing from what I can tell changed in the XML configuration, but I prefer to register my types by code instead. The only thing I really like to switch out from time to time is a Logger of some sort.

Another interesting aspect is the concept of child containers in their own sandbox as it were. Take for example, we have two loggers, a DebugLogger and a ConsoleLogger. We have the ability to have these registered in two different child containers all managed by the parent. Let's walk through a simple example of this.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            UnityContainer parentContainer = new UnityContainer();
            IUnityContainer childContainer1 = parentContainer.CreateChildContainer();
            childContainer1.RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager());
            IUnityContainer childContainer2 = parentContainer.CreateChildContainer();
            childContainer2.RegisterType<ILogger, DebugLogger>(new ContainerControlledLifetimeManager());
 
            ILogger logger1 = childContainer1.Resolve<ILogger>();
            ILogger logger2 = childContainer2.Resolve<ILogger>();
            logger1.Log("Foo");
            logger2.Log("Bar");
        }
    }
}

What seemed a little annoying to me is that CreateChildContainer is not available from the IUnityContainer, and instead only from the UnityContainer concrete class instead. But as you can see, I create two loggers each in their own sandbox, one a DebugLogger and one the ConsoleLogger.

What I'd Like To See

As I've said before, I'm not entirely sold on the Unity Application Block as I like a lot of the other ones in the Open Source Community as well including Castle Windsor, StructureMap and Spring.NET. It's heartening that they are taking a lot of advice from the community to heart and having quick drops for public approval. When people are evaluating IoC containers, it's critical that you have a list of essential features that the container must support. You may also note that your needs for this may change from project to project, so don't assume that if it worked well here that it will suit your needs on all projects. Due diligence must be done in tool and framework analysis to get the right tool for the right job.

With that in mind, I have a few things that I'm looking for right now in an IoC container. Some of these requirements are as follows:

Must be lightweight (No heavy XML lifting required)
Must support interception and AOP with runtime weaving (compile time might be nice)
Should be opinionated so that I don't need to mark my dependencies in my constructor, instead match by name
When I ask for a logger, give me one and I don't care which
Support easy object registration through fluent interfaces

But like I said, it evolves quickly and changes from project to project. What's your list and why?

Further Thoughts About IoC

Nick Malik recently blogged about IoC container and their overuse in a two part blog series here and here. In his first post, he tends to think that people are religious about the use of IoC containers and not just the Dependency Injection pattern in particular. In the second post, he covers that the use of the IoC container is only as good as the team that understands its impact and applicability. Most tools have their limits and uses. Mocking containers have the same issue. Once you start mocking for parts of your tests, then there is a good chance for abuse and overuse as well. I see his point, but I disagree that many teams are not up for IoC containers and general good design practices of Dependency Injection.

Wrapping It Up

Next time, I'd like to get into the extensibility model of each container in terms registering extensions and so on. In the mean time, I hope you go and evaluate your needs for an IoC container, even whether you need one or not. Until next time...

Live From Mix08

Matthew Podwysocki — Wed, 05 Mar 2008 19:34:07 GMT

No, I'm not at Mix08 right now, but I'm busy paying attention to every detail. I'm missing a lot of really cool things such as:

Silverlight downloads at 1.5 million a day
IE 8 preview with Firebug?
SQL Server Data Services

Also, now you can download IE8 already from here, so the news just keeps coming...

You can too by paying attention to the following places:

Live streaming video from Mix from Microsoft and some short videos on:
- IE 8
- Scott Guthrie
- Ray Ozzie
- Dean Hachamovitch
CodeBetter's live stream by Dave Laribee which features short snippets from the event.
Josh Holmes is covering the event and has noted about Ray Ozzie's keynote as well as other things.
John Lam will be at Mix as well and will be tweeting throughout the conference with his Twitter name john_lam. I know I'm following it now...

Also, if you're at Mix08, make sure you stop by to Josh Holmes's Open Spaces at Mix. You can find out more details about it here.

IoC Containers, Unity and ObjectBuilder2 - The Saga Continues

Matthew Podwysocki — Tue, 04 Mar 2008 08:15:34 GMT

Update: Fixed code changed from CTP and More in the series:

IoC Container, Unity and Breaking Changes Galore

I just wanted to revisit the whole Unity Application Block just once more to look at a few more things including handling parameters, instances and so on. If you hadn't seen, there was another source drop of Unity as of 2/26, so if you haven't picked it up, feel free to do so here.

So, we're going to continue our look at DI and IoC containers as they pertain to different needs. I'm not going to be a gloryhound about any particular IoC container, instead, just lay out how each one does its job and you decide whether you want to use it or not. And that's the main point I want to emphasize here that each tool has its purpose and its needs that it solves and it's up to you do decide whether it meets your needs and programming style.

Where We Are

Anyhow, I covered the Unity Application Block in a few other posts lately as it relates to other Inversion of Control (IoC) containers. I covered the basics with the Unity Application Block, StructureMap and Castle Windsor. Check them out before we go any further today:

Now that we're caught up to where we have been, let's dive into the other subjects in the same area of concern. Unity has an interesting way of dealing with several issues that I want to cover in respect to other IoC containers. And they are:

Managing Instances and Parameters
Method Call Injection
Unity Application Block versus ObjectBuilder2

Managing Instances or Parameters?

The previous two times, we talked about constructor injection and setter injection, but not really about managing simple types and mapping them to our constructors. It's usually a simple thing, but yet, we have three different ways of attacking the very same problem. That's the very point of these blog posts to point that out and it's once again echoed here.

To set up this scenario, we have a simple SmtpEmailService which is used to send emails to users in our system. It's a pretty naive sample, yet will illustrate some simple constructor injection with both simple and complex types. We're going to inject a default from address and a logger into our service and go from there.

We'll start with our Unity sample of how we are going to map those simple and complex types to the constructor. Let's start off with the basic logger interface and implementation. I'll only post this part once as it will apply the same to each of the samples.

namespace UnitySamples
{
    public interface ILogger
    {
        void Log(string message);
    }
}

And once again, we have our concrete implementation with the console logger.

using System;
 
namespace UnitySamples
{
    public class ConsoleLogger : ILogger
    {
        public void Log(string message)
        {
            Console.WriteLine(message);
        }
    }
}

Now, let's tie it together with the point of today's post, the SmtpEmailService. We will have two parameters in this scenario, the default email address, and the logger used for logging.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    public class SmtpEmailService : IEmailService
    {
        private readonly string defaultFromAddress;
        private readonly ILogger logger;
 
        public SmtpEmailService([Dependency("defaultFromAddress")] string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

As you may note, I'm using the DependencyAttribute to decorate the parameter defaultFromAddress. This correlates to the key specified in the config file or when you register an instance, and I'll show you that later.
Let's take a look at the program.cs to use the XML config file to wire up our instances.

using System.Configuration;
 
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

The above code is pretty standard as we've used before, so real surprises here. So, let's take a look at the XML configuration necessary to make this work:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="unity"
                type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
                  Microsoft.Practices.Unity.Configuration" />
    </configSections>
    <unity>
        <containers>
            <container>
                <types>
                    <type type="UnitySamples.ILogger,UnitySamples"
                          mapTo="UnitySamples.ConsoleLogger,UnitySamples"
                          lifetime="Singleton"/>
                </types>
                <instances>
                    <add name="defaultFromAddress" type="System.String" value="administrator@example.com" />
                </instances>
            </container>
        </containers>
    </unity>
</configuration>

What I did is that I utilized the instances node and then add an instance called defaultFromAddress. This node is only used to initialize simple types such as strings, DateTimes, System.Doubles, System.Int32 and so on. Then I can set the value as well. So, if I want to initialize complex types in the types node and the simple types in the instances node.

But, we can also register things through the regular programmatic interfaces as well such as this:

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            container
                .Register<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
                .RegisterInstance<string>("administrator@example.com", "defaultFromAddress");
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

As you note, I used the fluent interfaces approach to register the ConsoleLogger as well as the instance of type string which had my value and the key I wanted to use. The first value I use is the value, and the second is the key I want to use to correlate to my DependencyAttribute.

Now, let's look at the StructureMap instance using the same approach. The only pieces I intend to show are just the pieces I changed. So, let's take a look at the SmtpEmailService once again.

namespace StructureMapSamples
{
    public class SmtpEmailService : IEmailService
    {
        private readonly string defaultFromAddress;
        private readonly ILogger logger;
 
        public SmtpEmailService(string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

As you may note from above, I had no need for the dependency attribute or anything like that. I haven't bothered to put the PluginAttributes or anything like that either as I want to do XML config way. So, let's next look at the program.cs which does the simple email wireup.

using StructureMap;
 
namespace StructureMapSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            SmtpEmailService service = ObjectFactory.GetInstance<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

And then we wire things up with our StructureMap.config file. Note that we set up things through an Instance node and then set the constructor injection parameters through property nodes.

<?xml version="1.0" encoding="utf-8" ?>
<StructureMap>
    <Aseembly Name="StructureMapSamples"/>
  <PluginFamily Type="StructureMapSamples.ILogger" Assembly="StructureMapSamples" DefaultKey="Console" Scope="Singleton">
    <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.ConsoleLogger" ConcreteKey="Console" />
    </PluginFamily>
  <PluginFamily Type="StructureMapSamples.SmtpEmailService" Assembly="StructureMapSamples" DefaultKey="EmailService">
      <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.SmtpEmailService" ConcreteKey="SmtpEmailService" />
      <Instance Key="EmailService" Type="SmtpEmailService">
          <Property Name="defaultFromAddress" Value="administrator@example.com" />
          <Property Name="logger" Key="Console" />
      </Instance>
  </PluginFamily>
</StructureMap>

I tidied up the XML configuration a bit after taking Jeremy Miller's advice and trying to collapse it down as much as possible. I'm sure I still don't have it to the smallest amount possible, but at least it's legible. Now, let's go ahead and use the DSL for configuration instead of the simple program.cs we have above.

using StructureMap;
using StructureMap.Configuration.DSL;
 
namespace StructureMapSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            StructureMapConfiguration.UseDefaultStructureMapConfigFile = false;
            StructureMapConfiguration.BuildInstancesOf<ILogger>()
                .TheDefaultIsConcreteType<ConsoleLogger>().AsSingletons();
            StructureMapConfiguration.BuildInstancesOf<SmtpEmailService>().TheDefaultIs(
                Registry.Instance<SmtpEmailService>().UsingConcreteType<SmtpEmailService>()
                    .WithProperty("defaultFromAddress").EqualTo("administrator@example.com"));
            SmtpEmailService service = ObjectFactory.GetInstance<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

As you can see from above, it's a pretty simple thing to use the more fluent interfaces here as well to register what we're interested in. We're making sure it doesn't use the default StructureMap.config file and then build up an instance of an ILogger as a singleton, and then use the injection on the SmtpService to set the defaultFromAddress. The ILogger it should automatically figure out itself.

Now, let's finally move onto Castle Windsor. I must admit, I'm most familiar with Castle Windsor, but I'm learning something new about each of these every day, which is a good thing. So, the only classes I really need to show is the program.cs and the configuration file to show what has changed. So, let's start with the program.cs file:

using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer(new XmlInterpreter());
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

This is a pretty simple example of using the XmlInterpreter which reads the XML configuration file to read what we want to set. And then our XML configuration file should look something like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="castle"
            type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
    </configSections>
    <castle>
        <components>
            <component id="emailservice.smtp"
                type="CastleSamples.SmtpEmailService, CastleSamples">
            <parameters>
                <defaultFromAddress>administrator@example.com</defaultFromAddress>
            </parameters>
        </component>
        <component id="logger.console"
                       service="CastleSamples.ILogger, CastleSamples"
                       type="CastleSamples.ConsoleLogger, CastleSamples"
                       lifestyle="singleton" />
        </components>
    </castle>
</configuration>

I could have also specified the logger as well as a parameter by noting it inside the parameters node such as this:
<logger>${logger.console}</logger> to specify that it uses the ConsoleLogger, but it's not really necessary to do so.

Instead, let's use the XML free way of configuration just to prove a point we can do it both ways:

using System.Collections.Generic;
using Castle.Core;
using Castle.Windsor;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer();
            container.AddComponentWithLifestyle("logger.console", typeof (ILogger), typeof (ConsoleLogger),
                                                LifestyleType.Singleton);
            Dictionary<string, object> properties = new Dictionary<string, object>();
            properties.Add("defaultFromAddress", "administrator@example.com");
            container.AddComponent("emailservice.smtp", typeof (SmtpEmailService));
 
            SmtpEmailService service = container.Resolve<SmtpEmailService>(properties);
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

So, as you can see, it's pretty simple to set the parameters on our SmtpEmailService through the use of a Dictionary<TKey, TValue> generic collection. The rest is just plain simple.

Method Call Injection

The Unity Application Block introduces another concept called method call injection. Yes, that's right, instead of using constructor injection or setter injection, you can use method call injection. The basic premise is that you can inject any method as you would for a constructor or setter.

When would you use this though? If you read the documentation, it lays out the explanation as follows:

You want to instantiate dependent objects automatically when your instantiate the parent object
You want a simple approach that makes it easy to see in the code what the dependencies are for each class
The parent object requires a large number of constructors that forward to each other, making debugging and maintenance difficult
The parent object constructors require a large number of parameters, especially if they are of similar types and the only way to identify them is by position
You want to hide the dependent objects by not exposing them as properties
You want to control which objects are injected by editing the code of the dependent object instead of the parent object or application

By default unless any of this matches your criteria, you should just go ahead and use constructor injection. But, let's walk through a small sample of using method injection:

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    public class SmtpEmailService : IEmailService
    {
        private string defaultFromAddress;
        private ILogger logger;
 
        [InjectionMethod]
        public void Initialize([Dependency("defaultFromAddress")] string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

The rest of our program shouldn't have to change with this scenario. But, as you will note from above, we decorated our Initialize method with an InjectionMethodAttribute which makes it realize that instead of constructor injection, use this instead. And it works like a charm. I haven't run into a scenario yet where I would find it useful, but I find it interesting. If anyone does have a scenario that they've run into, please let me know.

Unity == ObjectBuilder2?

As you may have noticed, if you had downloaded the Unity Application Block, you'll notice that it is built upon ObjectBuilder2, but you may also notice that it hides a lot of functionality that it provides. When you are marking your classes with DependencyAttribute and other things, you will notice that there are two of them, one in Unity and one in ObjectBuilder2, so this got me curious on what else I was missing out on.

If you've played around with Enterprise Library in the past, you have probably dealt with ObjectBuilder. It was not the most delightful piece of code I've ever had to deal with and not very intuitive. Brad Wilson and Scott Densmore took it upon themselves to rewrite this into a much more usable piece of code. You can download the original and unencumbered ObjectBuilder2 from CodePlex here.

Take a look at the CodePlex DependencyInjection project and its associated tests in Tests.CodePlex.DependencyInjection for a good idea on how well Brad and Scott did with their DI framework. The best way to learn about any framework is to read the tests or specs (BDD style of course). Let's look at two ways of doing code interception using the DI framework with using code and using attributes.

            [Fact]
            public void InterceptViaAttributes()
            {
                Recorder.Records.Clear();
                DependencyContainer container = new DependencyContainer();
                container.RegisterTypeMapping<ISpy, SpyInterfaceAttributes>();
 
                ISpy obj = container.Get<ISpy>();
                obj.InterceptedMethod();
 
                Assert.Equal(3, Recorder.Records.Count);
                Assert.Equal("Before Method", Recorder.Records[0]);
                Assert.Equal("In Method", Recorder.Records[1]);
                Assert.Equal("After Method", Recorder.Records[2]);
            }
 
            [Fact]
            public void InterceptViaCode()
            {
                Recorder.Records.Clear();
                DependencyContainer container = new DependencyContainer();
                container.RegisterTypeMapping<ISpy, SpyInterface>();
                container.InterceptInterface<SpyInterface>(typeof(ISpy).GetMethod("InterceptedMethod"),
                                                           new RecordingHandler());
 
                ISpy obj = container.Get<ISpy>();
                obj.InterceptedMethod();
 
                Assert.Equal(3, Recorder.Records.Count);
                Assert.Equal("Before Method", Recorder.Records[0]);
                Assert.Equal("In Method", Recorder.Records[1]);
                Assert.Equal("After Method", Recorder.Records[2]);
            }

Ok, so you may note that we registered this with an ISpy interface. Then we have two implementations, one with code and one using attributes. Let's now inspect that code.

            public interface ISpy
            {
                void InterceptedMethod();
                void ThrowsException();
            }
 
            internal sealed class SpyInterface : ISpy
            {
                public void InterceptedMethod()
                {
                    Recorder.Records.Add("In Method");
                }
 
                public void ThrowsException()
                {
                    Recorder.Records.Add("In Method");
                    throw new Exception();
                }
            }
 
            internal sealed class SpyInterfaceAttributes : ISpy
            {
                [InterfaceIntercept(typeof(RecordingHandler))]
                public void InterceptedMethod()
                {
                    Recorder.Records.Add("In Method");
                }
 
                public void ThrowsException()
                {
                    throw new Exception();
                }
            }
        }

As you may note, we have two methods that we're interested in, the InterceptedMethod and the ThrowsException method. Then we can test through a Recorder that in fact the code was hit. xUnit.net is used quite frequently throughout the code as it is a project also by Brad and Jim Newkirk. Overall, I'm very impressed with this code and I wish it had made more of an impact.

Chris Tavares and others from the Unity team have taken it upon themselves to redo a lot of the guts of ObjectBuilder2 as they continue to extend Unity. For AOP, the plan is to include the Policy Injection Block into the solution, whereas ObjectBuilder2 already had this piece of functionality and does it quite well. Some of it seems to be right now a little less featured than ObjectBuilder2 at this point, but that can change. I have hopes for Unity, but ObjectBuilder2 did a lot of these things that it claims to do, just a little bit better.

Wrapping it Up

Here wraps up another installment of looking at IoC containers and the various frameworks associated with it. I hope that it whets your appetite to not only understand these containers, but see how they work deep down and see which matches your programming style. Get to know your tools just a little bit better and find out what good quality code can be. I hope you can take this to heart and see what works for you.