In June this year an article from my hand about Aspect Oriented Programming (AOP) was published in the Dutch .NET Magazine. It's about partly about AOP in general and partly about the usage of PostSharp. You can download the article here. You can read about my other articles here and here. Let me know what you thing about the article.

I did show it in my fourth article about Silverlight Networking, using a functionpointer in a call instead of a return type. This was to get the JavascriptWebResponse back asynchronous.

Working with the Silverlight Networking stack is only possible asynchronously. So we need to provide a callback function that get's called after execution. All the Silverlight examples I've seen have this callback function in the User Interface. But what about all the classes that have their own responsibility that normally live in between the User Interface and the actual call to the Networking stack? I'm sure I don't want to call the Networking stack right from the UI. I normally have at least one class between the UI and the Network call that does some transformation, preparation and other things. Let's have a solution that I designed for Silverlight but also works within the full CLR.

The Example Situation

For this example I was working on a simple Delicious application that only shows the Tags that are within your Delicious account. I do have two responsibilities that are covered inside the Delicious application, namely the compilation of the JavascriptWebRequest (IDeliciousConnector) and the transformation of a xml-based string to real Tag objects (IDeliciousService). I won't cover the the IWebRequestExecutor

The situation with return types

When we convert the example situation to a UML Sequence Diagram we get something like the following diagram.

The implementation with end-of-call function pointers

First of all I created the generic AsyncEventArgs class. It's very easy and only has one property called Result that you can be typed exactly the same as you would normally type the return type. The looks of AsyncEventArgs is as follows.

1 public class AsyncEventArgs<T> : EventArgs
2 {
3   public T Result { get; set; }
4 }

Easy isn't it? So instead of specifying a return type we now make every method of type void. And we add a callBack parameter to the method that's an AsyncEventArgs EventHandler of the return type. At the end of the execution we call the callBack function with the typed AsyncEventArgs parameter.  This results in the following Sequence Diagram, no return messages but just only message calls. In effect the callBack is a function pointer parameter so the IDeliciousConnector doesn't really know about the IDeliciousService, but it sort of looks like the diagram.

The implementation of the interface is not that different, no voids anymore as you can see and a lot of callBack function pointers.

 1 public interface IDeliciousService
 2 {
 3   void GetTags(EventHandler<AsyncEventArgs<IList<Tag>>> callBack);
 4 }
 5 
 6 public interface IDeliciousConnector
 7 {
 8   void GetTags(EventHandler<AsyncEventArgs<string>> callBack);
 9 }
10 
11 public interface IWebRequestExecutor
12 {
13   void Execute(JavascriptWebRequest request,
14                EventHandler<JavascriptResponseEventArgs> functionToCallOnResponse);
15 }
16 

Let's do some implementation.

Time for the method implementation

For the implementation I make much use of anonymous methods. As a start the implementation of IDeliciousConnector.GetTags. I started with a call to the webRequestExecutor which also expects a function parameter. I expect the WebResponse to be part of the eventArgs so if everything goes well I will be calling my callBack with only the WebResponse.Body as string in lines 16-18.

 1 public void GetTags(EventHandler<AsyncEventArgs<string>> callBack)
 2 {
 3   var webRequest = new JavascriptWebRequest();
 4   //Some construction of the webRequest
 5   webRequestExecutor.Execute(
 6     webRequest,
 7     (sender, eventArgs) =>
 8     {
 9       if (eventArgs.WebResponse == null)
10         throw new Exception("Something went wrong. No WebResponse was available.");
11       if (eventArgs.WebResponse.StatusCode != "200")
12         throw new Exception(
13           string.Format("Expected statuscode 200 but was actually {0}",
14               eventArgs.WebResponse.StatusCode));
15       if (callBack != null)
16         callBack(this,
17           new AsyncEventArgs<string>
18             {Result = eventArgs.WebResponse.Body});
19     });
20 }

Time for the implementation of the IDeliciousService.GetTags which will "return" a list of Tags. I used Linq2Xml for translating the Xml inside the string to a list of objects, see lines 7-16. And at the end I call the callBack function with the list of tags as result property in line 18.

 1 public void GetTags(EventHandler<AsyncEventArgs<IList<Tag>>> callBack)
 2 {
 3   deliciousConnector.GetTags(
 4     (sender, eventargs) =>
 5       {
 6         string tagsXml = eventargs.Result;
 7         XElement tagsElement = XElement.Load(new StringReader(tagsXml));
 8         IEnumerable<Tag> tags =
 9           from tagElement in tagsElement.Descendants()
10           select new Tag
11             {
12               Count =
13                 Convert.ToInt32(
14                 tagElement.Attribute("count").Value),
15               Name = tagElement.Attribute("tag").Value
16             };
17       if(callBack!=null)
18         callBack(this, new AsyncEventArgs<IList<Tag>> {Result = tags.ToList()});
19     });
20 }

I think this implementation is pretty clean, because almost everything happens inside of the anonymous method. There isn't very much of magic glue, only an anonymous method with a generic AsyncEventArgs object. But it's also important to test these kind of code. Let's go over to the testing.

How to test this kind of code?

In the situation when we have just a return type we can easily assert if it's the way we like it. But in the situation of async the Test method must be instructed to wait for the result to be available before testing the result. So the following code won't work most of the time.

 1 [Test]
 2 public void ExpectReturnOf8TagsWrong()
 3 {
 4   IDeliciousService sut = SUT();
 5   IList<Tag> tags = null;
 6   sut.GetTags((sender, eventargs) =>
 7     {
 8       tags = eventargs.Result;
 9     });
10   Assert.AreEqual(8, tags.Count);
11 }

A better implementation will be by using a waitHandle, which will work.

 1 [Test]
 2 public void ExpectReturnOf8TagsGood()
 3 {
 4   IDeliciousService sut = SUT();
 5   IList<Tag> tags = null;
 6   var waitHandle = new ManualResetEvent(false);
 7   sut.GetTags((sender, eventargs) =>
 8     {
 9       tags = eventargs.Result;
10       waitHandle.Set();
11     });
12   waitHandle.WaitOne();
13   Assert.AreEqual(8, tags.Count);
14 }

I hope everyone thinks this article to be interesting. If anyone does have something to add I'd like to know. And don't have any license for a real UML tool so I can't help there are watermarks all over the images.

I think a lot of people don't like the way Workflow Foundation parameters work. At least I totally dislike it. I don't want to use an almost untyped (yes, we have object as type) dictionary to read values, and besides why do we need to cast, the types are available. Instead of using basic strings for the parameter naming, I have a different approach. I add an static inner class to the Workflow codebeside.

1 public static class Parameters
2 {
3     public const string BaseFolder = "BaseFolder";
4     public const string AnalysisResult = "AnalysisResult";
5 }

When inside the Parameters class I also have a ReSharper Live Template, stpar:

public const string $ParamName$ = "$ParamName$";

In this example I can use the workflow parameter names by using :

WorkflowName.Parameters.BaseFolder

You now have to add a real C# property with the same name as we have in the Parameters class. But much less work, and through this approach we won't make that many mistakes in the string-based key.

Besides this the use of a basic Dictionary isn't that readable too. So I created a somewhat fluent interface for use with Dictionary<TKey,TValue>. So we can create a dictonary more readable than the basic way.

1 FluentDictionary<string, object> parameters = new FluentDictionary<string, object>()
2     .Add(AdministrationAnalysis.Parameters.BaseFolder, @"C:\")
3     .Add(AdministrationAnalysis.Parameters.AnalysisResult, null);

So here''s the code for the FluentDictionary:

 1 public class FluentDictionary<TKey, TValue>
 2 {
 3     private readonly Dictionary<TKey, TValue> internalDictionary = new Dictionary<TKey, TValue>();
 4 
 5     public FluentDictionary()
 6     {
 7     }
 8 
 9     public FluentDictionary(Dictionary<TKey, TValue> internalDictionary)
10     {
11         this.internalDictionary = internalDictionary;
12     }
13 
14     public Dictionary<TKey, TValue> Dictionary
15     {
16         get { return internalDictionary; }
17     }
18 
19     public int Count
20     {
21         get { return internalDictionary.Count; }
22     }
23 
24     public FluentDictionary<TKey, TValue> Add(TKey key, TValue value)
25     {
26         internalDictionary.Add(key, value);
27         return this;
28     }
29 
30     public void Clear()
31     {
32         internalDictionary.Clear();
33     }
34 
35     public bool ContainsKey(TKey key)
36     {
37         return internalDictionary.ContainsKey(key);
38     }
39 
40     public bool ContainsValue(TValue value)
41     {
42         return internalDictionary.ContainsValue(value);
43     }
44 
45     public TTyped Get<TTyped>(TKey key) where TTyped : TValue
46     {
47         return (TTyped) internalDictionary[key];
48     }
49 }

Let me know if you like this approach or if you have a better solution.

Just about two weeks ago the Microsoft patterns & practices team released a Community Technology Preview of the Unity project. Unity is a lightweight Dependency Injection Container. I've just been using it in some very basic scenario's, so far I like it. It has support for constructor and property injection. But also, a thing not many Dependency Injection container support I think, the ability to do method call injection.

David Hayden has some post on Unity on his blog. But most of all he has created a screencast on Unity, very nice to get an introduction to Unity.

Unity already gets some attention on the Internet. Oren Eini, a guy that's very experienced on Dependency Injection and did some coding on Castle Windsor another Dependency Injection container, has done a review on Unity.

Let's wait for the final release. Maybe I will add it to my toolbox. It still seams customers like open source projects from Microsoft more than open source projects from different hand. Maybe I will be able to apply Dependency Injection using Unity at a customers place.

I haven't been able to use an IoC container on a real-world project yet. And even though I've been doing some research on it, I still have questions regarding IoC container usage.

I always thought about using the Application var for storing the container instance for an ASP.NET application. For other application I would use a static class or static var for the container instance. But thinking about this more and more, I'm not sure about this approach.

What approach do you think is the most sufficient way to share the container instance? Or should we not even share the container instance at all?