current community

your communities

more stack exchange communities

Stack Exchange
tour help
stack overflow careers
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 3 down vote favorite

Ninject, Sprint.NET, Unity, Autofac, Castle.Windsor are all examples are IoC frameworks that are available. However, I like the learning curve and control of writing my own. It is definitely common practice to not "re-invent the wheel" and just use pre-existing structures. If your comment is along those lines please be gentle.

Can IoC be implemented without the use of XML? It seems to me most, if not all, of the aforementioned frameworks use XML but I would much rather just write mine in C# instead of using XML to load a .dll. The C# is all converted into one .dll eventually anyway.

From my understanding, if wrong please correct, IoC can be used with DI to make the functionality of classes be based off of their definition and implementation while allowing for a separation of concerns.

This is accomplished in C# using microsoft's library System.ComponentModel.IContainer by having a class which inherits it. A class, such as Product, would have an interface IProduct. A generic constructor would then inherit from IContainer and in the constructor, allow a repository to be passed in, an instantiated object to be passed in, and a function to be passed in. This would allow a controller action to then instantiate an interface (IProduct), instantiate the generic constructor with the current repository instance, and then pass it the interface and function.

Is this setup accurate?

I am still trying to learn more about this topic, and have read the wiki articles on IoC, DI, and read about Castle.Windsor, ninject, Unity, and looked over multiple definitions from the MSDN regarding C# libraries which are used. Any assistance, corrections, or suggestions, are greatly appreciated. Thanks

share|improve this question
3  
All of those IoC containers support configuration in code rather than XML as well –  BrokenGlass Jan 27 '12 at 21:48
    
@BrokenGlass - thanks, I didn't know that. So it is possible to make mine all in code as well then :) –  Travis J Jan 27 '12 at 21:50
3  
Ninject doesn't even have an XML option, it's enitrely in code. Most of the others allow code configuration or xml. –  Erik Funkenbusch Jan 27 '12 at 21:55
    
@BrokenGlass could you please confirm that recent versions of Sprint.net support in-code configureation? –  Restuta Jan 27 '12 at 22:06
1  
@MystereMan this is not correct. Ninject has Xml configuration support. But like most things that are not a must have, it requires an extension so that you can put together all the features that are relevant to you. –  Remo Gloor Jan 27 '12 at 23:52

3 Answers 3

up vote 5 down vote accepted

I think it is a great exercise to start without a DI container. Before focusing on using a DI framework, focus on best patterns and practices. Especially, design all classes around Dependency Injection and make sure your code follows the SOLID principles. Both sounds pretty easy, but this takes a shift in mindset and a lot of practice before you will get this right (but is well worth it).

When you do this, and do this well, you will quickly notice that your application will evolve in amazing ways. Your code will be testable and extendable in ways that you never imagined before, without your code to rot over time (however, it keeps constant focus to prevent code from rotting).

Still, when you do all this right (which –again- takes a lot of practice), you will still have one part of your application that, despite your best efforts, will get more complex and harder to maintain, as the application grows. This is the part of the application where you wire all dependencies together: the Composition Root.

And this is where DI containers come in. They have fancy names and compete with each other over features, but their goal can be stated in a single sentence:

The goal of a DI container is to keep the Composition Root maintainable.

Although you can write your own simple DI container to wire up your dependencies, to prevent your Composition Root to become a big fragile, ever changing ball of mud, the container must at least have one crucial feature: Automatic Constructor Injection (a.k.a. auto-wiring). With auto-wiring, the container will look at the constructor arguments of a type that it needs to create, and it will inject the dependencies in it based on the types of those arguments. This feature will make the difference between a maintenance nightmare and a healthy Composition Root. Although creating your own container that supports auto-wiring isn't that hard (with expression trees it takes about 20 lines of code), the moment you start needing auto-wiring is the time to start using one of the existing DI frameworks.

So in conclusion, if you feel it helps you in the learning experience by doing this by hand, please do, as long as you stick to SOLID, DI, DRY, and TDD. When the burden of changing your Composition Root for each change in the application gets too big (which will be sooner than you might expect), switch to an established framework.

share|improve this answer
    
Good point, but I wouldn't say that "S" from "SOLID" is easy. This is most hard-to-follow principle comparing to others. –  Restuta Jan 31 '12 at 1:52
    
I never said it was easy. I said it takes a lot of practice. –  Steven Jan 31 '12 at 7:40
    
I never said that you said that :Р it was just a note to put attention to. –  Restuta Feb 1 '12 at 0:16
    
In that case we agree :-) –  Steven Feb 1 '12 at 8:29
up vote 8 down vote

Can IoC be implemented without the use of XML?

Yes, Ninject, Unity, Castle Windsor and Autofac can be configured without using any XML at all. (not sure about Spring.NET, last time I used it it was impossible, version 1.3)

From my understanding, if wrong please correct, IoC can be used with DI to make the functionality of classes be based off of their definition and implementation while allowing for a separation of concerns.

If under "IoC" you mean "IoC container" then yes, it can be used with DI, but since DI is a particular case of Inversion Of Control your IoC container will be just a container for you dependencies. By just having it your will not magically get any DI-friendly types. It's just a support for managing your inverted dependencies.

Edit

As Mystere Man pointed in his answer you need to improve you understanding of the IoC containers. So I would recommend to read this wonderful book (from Mark Seeman) about all that stuff.

share|improve this answer
    
This does seem to be a good book. In an interview about the book, Mark Seeman repeatedly talks about DI Containers. In fact, I did not realize that (is this correct) DI is a type of IoC. Furthermore, ( martinfowler.com/articles/injection.html ) there are various types of injection (notably 3). Is implementing Dependency Injection considered an Inversion Of Control? –  Travis J Jan 27 '12 at 22:18
2  
DI is definitely a sub-type of IoC. As Martin states in his article IoC term is to generic to use, so he restricts the topic to just DI and then describes several types of DI implementation. And since DI considered a form of IoC the answer on your last question is "yes". –  Restuta Jan 27 '12 at 22:25
    
What do you mean by "DI-friendly types"? –  Travis J Jan 27 '12 at 22:41
    
DI-friendly types are types that have no implicit dependencies, but explicit ones. So the better term would be "DI-ready" =) –  Restuta Jan 27 '12 at 23:18
up vote 2 down vote

I would suggest using an existing DI container first, to understand how it works from the end user perspective. Then you can go about re-designing the wheel. My favorite saying is "You have to know the rules before you can break them".

Some of what you've said doesn't make a lot of sense. you don't have to use System.ComponentModel.IContainer in any framekwork i know of. Maybe Unity requires that (Microsoft's container) but none of the others do. I'm not familiar with Unity thogh.

share|improve this answer
1  
+1, you don't seem to understand the use of DI containers, so trying to write one would be a train wreck. Check out Mark Seeman's Dependency Injection in .NET. –  Domenic Jan 27 '12 at 22:00
    
The IContainer is used to add Dependency Injection capabilities, and would not need to be coded if I simply used a framework. –  Travis J Jan 27 '12 at 22:06
1  
Nothing need to be used to add a Dependency Injection capabilities in C#, this principle is independent and can be used with basic language features. –  Restuta Jan 27 '12 at 22:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.