C#, Lambdas / Anonomous delegates

Barbarian IOC

At work I have used a variety of IOC Containers including

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:

  1. Instance configuration : singleton / transient
  2. Simple registration process, maybe some sort of fluent interface
  3. Use the Expression API to compile into delegates for quick creation of  objects
  4. Constructor / property injection
  5. 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.



If you want to read more you can grab the rest of the article and the source over at codeproject : http://www.codeproject.com/Articles/552514/BarbarianIOC-A-simple-IOC-Container