And I have used others such as Unity/StructureMap/AutoFac. They are all very good and very rich.

For those of you who don’t know what IOC stands for, it stands for Inversion Of Control. Which is described as follows:

In software engineering, inversion of control (IoC) is a programming technique, expressed here in terms of object-oriented programming, in which object coupling is bound at run time by an assembler object and is typically not known at compile time using static analysis.

In traditional programming, the flow of the business logic is determined by objects that are statically assigned to one another. With inversion of control, the flow depends on the object graph that is instantiated by the assembler and is made possible by object interactions being defined through abstractions. The binding process is achieved through dependency injection, although some argue that the use of a service locator also provides inversion of control.

In order for the assembler to bind objects to one another, the objects must possess compatible abstractions. For example, class A may delegate behavior to interface I which is implemented by class B; the assembler instantiates A and B then injects B to A.

In practice, inversion of control is a style of software construction where reusable code controls the execution of problem-specific code. It carries the strong connotation that the reusable code and the problem-specific code are developed independently, which often results in a single integrated application. Inversion of control as a design guideline serves the following purposes:

There is a decoupling of the execution of a certain task from implementation.

Every module can focus on what it is designed for.

Modules make no assumptions about what other systems do but rely on their contracts.

Replacing modules has no side effect on other modules.

Inversion of control is sometimes facetiously referred to as the "Hollywood Principle: Don’t call us, we’ll call you", because program logic runs against abstractions such as callbacks.

Wikipedia : up on date 25/02/2013

Thing is I have always wanted to try and make one of these myself, just to see what is involved. I did not want to go too nuts on this, and just wanted the following really:

Instance configuration : singleton / transient

Simple registration process, maybe some sort of fluent interface

Use the Expression API to compile into delegates for quick creation of objects

Constructor / property injection

Provide the ability to accept non IOC held constructor parameters

So those couple of points are ALL I wanted to get working. As I say there are a whole slew of full fledged IOC containers out there (where I have named a few above), this articles container is more of a learning exercise, that I thought I would share, in case anyone else is interested in this sort of thing.

I am calling my container BarbarianIOC as the existing containers all seems to have these short snappy names, and it’s kind of play on my name, and if you saw me without a shave I do kinda look a bit like a barbarian.

Some of you may remember a rather handy ExpressionTree debugger visualizer that allowed the visualization of expressions. Basically it was extremely handy and a great way of getting to know the Expression API a bit better.

Unfortunately this was a VS2008 sample, and it does not seem to come with VS2010.

I had not been missing it as I have not been doing much with Expressions, that is until the other day, and I really started to miss it. So I set about trying to get it to work.

Change the references to point to this location for the DebuggerVisualizers.dll : C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.VisualStudio.DebuggerVisualizers.dll

Worked a treat and for those of you that are simply to lazy to do this work, here is zip file containing a valid VS2010 copy of a C# project that will build this Expression Debugger Visualizer for you:

The other day I wrote a bit of reflection inside an ASP .NET custom ModelBinder class to call a generic method, and my work colleague asked, isnâ€™t that going to be slow.

I was like yeah but not that bad, besides if it proves to be a problem we can always speed it up using method caching and Expression Trees.

He then asked to see an example of that as he had not done too much with Expression Trees, I said sure I would knock one up for him.

The idea is a fairly simply one, we can to call a method, I was using Reflection which takes the Reflection hit every time, so what we need is to build up a Dynamic Delegate which we can store and which we can then call each time which will be lightning quick when compared to using Reflection, as all we are doing is calling a Delegate.

You can see that this method is generic and takes a string as a parameter. So what would an expression tree builder method look like, and what it would it return. Well it would look like this, and would return a Func delegate which we could cache somewhere, and call next time, which as I say would be very fast, as we are not doing any Reflection any more, we basically take the hit one when we 1st create the Func delegate.

The other day I was messing around with an idea I had where I had a object graph of related objects which looked something like this (where each object was an INotifyPropertyChanged object).

And I thought wouldnâ€™t it be nice if I could observer changed from any of those object conveniently, and without the need to hook/unhook when new object were introduced into the object graph.

So I had a think and came up with a bunch of classes that do allow me to observe changes in a chain of objects, and do so in a kind of fault tolerant manner, where replacement objects could be brought into the chain, without any adverse affect to the INPC listeners.

The main class I came up with is called ChainPropertyObserver and can be used as simply as this:

But if you just want a quick overview, what the Tasks in the System.Threading.Tasks VS2010 Namespace are all about (from what I read anyhow), is a replacement for queuing work items up using the currently available ThreadPool. The issue with the current ThreadPool is that

Work items can’t return a value

Can not cancel tasks

No waiting on work items

Composing a group of items in a structured way

Handling exceptions thrown concurrently or any other richer construct built on top of it

So Tasks are there to help out in this area. Let’s have a quick look at how to do some common things such as

I was at work today and had to deal with obtaining the values from some anonomous types that I was using in some WPF databinding, and although I knew I could do it with reflection, I thought someone else may have already done something, and low and behold I found something pretty cool. I found this chap that wrote a nice wrapper around an anonomous type that lets you access the property values using generics for the type of the propertyÂ and strings for the key of the property. He also allows you to add new methods to the anonomous type using delegates/lambdas, all in all its a good effort. Have a look for yourself over at his blog

A couple of posts ago I showed you all how to use CodeDom/CompilerServices and LINQ to create a dynamically created dll. A few people stated that this should have been in a new AppDomain (and it was already this way at work), so I have updated the example post to show you how to create a dynamic assembly in a new AppDomain. Have a look at the original post here : http://sachabarber.net/?p=496

Essentially what Marlon did was create a message system to allow disparate MVC classes to communicate with each other. The original code by Marlon was spot on, but I just didn’t like the way he was using strings for his messages, but other than that there is very little change from my code here to his code. So well done Marlon, you are ace.

Anyway the idea behind Marlons original post was using the MVC pattern along with an additional class called the Mediator whom knew about messages and who to notify when something happened that warrants a message being sent out.

These days most folk will use the MVVM pattern when developing WPF. I have a small demo app that does the following.

It has 2 textboxes, one of which is a writable textbox, which is used to send messages via the Mediator

The 2nd textbox is refreshed via the message that is sent via the Mediator when the 1st textbox changes

Lets have a look at some code:

1st a helper class (lifted from Marlons blog)

1: using System;

2: using System.Collections.Generic;

3: using System.Linq;

4: using System.Text;

5:

6: namespace MediatorDemo

7: {

8: /// <summary>

9: /// The multi dictionary is a dictionary that contains

10: /// more than one value per key

11: /// </summary>

12: /// <typeparam name="T">The type of the key</typeparam>

13: /// <typeparam name="K">The type of the list contents</typeparam>

14: publicclass MultiDictionary<T, K>

15: : Dictionary<T, List<K>>

16: {

17:

18: #region Private Methods

19: //checks if the key is already present

20: privatevoid EnsureKey(T key)

21: {

22: if (!ContainsKey(key))

23: {

24: this[key] = new List<K>(1);

25: }

26: else

27: {

28: if (this[key] == null)

29: this[key] = new List<K>(1);

30: }

31: }

32: #endregion

33:

34: #region Public Methods

35: /// <summary>

36: /// Adds a new value in the Values collection

37: /// </summary>

38: /// <param name="key">The key where to place the

39: /// item in the value list</param>

40: /// <param name="newItem">The new item to add</param>

41: publicvoid AddValue(T key, K newItem)

42: {

43: EnsureKey(key);

44: this[key].Add(newItem);

45: }

46:

47:

48: /// <summary>

49: /// Adds a list of values to append to the value collection

50: /// </summary>

51: /// <param name="key">The key where to place the item in the value list</param>

52: /// <param name="newItems">The new items to add</param>

53: publicvoid AddValues(T key, IEnumerable<K> newItems)

54: {

55: EnsureKey(key);

56: this[key].AddRange(newItems);

57: }

58:

59: /// <summary>

60: /// Removes a specific element from the dict

61: /// If the value list is empty the key is removed from the dict

62: /// </summary>

63: /// <param name="key">The key from where to remove the value</param>

64: /// <param name="value">The value to remove</param>

65: /// <returns>Returns false if the key was not found</returns>

66: publicbool RemoveValue(T key, K value)

67: {

68: if (!ContainsKey(key))

69: returnfalse;

70:

71: this[key].Remove(value);

72:

73: if (this[key].Count == 0)

74: this.Remove(key);

75:

76: returntrue;

77: }

78:

79: /// <summary>

80: /// Removes all items that match the prediacte

81: /// If the value list is empty the key is removed from the dict

82: /// </summary>

83: /// <param name="key">The key from where to remove the value</param>

This simply allows more than 1 object to be registered for a particular message

Next comes the Mediator which is a singleton, and know how to send and register messages against callback, which is what I have changed. In Marlons original code he used Strings, where as I am now using Action<Object> delegates as callbacks. A minor improvement I feel.

And how about dealing with a message from the Mediator, this is fairly simple, though we do have to cast the results from Object to the Type we are expecting. This is necessary as the Mediator uses Action<Object> delegates as callbacks, where Object could be any Type of course.

And that is really all there is to it. You now have a Writer ViewModel that will notify a totally disconnected Reader ViewModel about a change, via the messaging providing by the Mediator/Action<Object> delegate callbacks, that were registered for the message by the class that wants to do something based on the message being registered with the Mediator.