Replace Spring.Net IoC with another Container (e.g. Ninject)

Question

I'm curious to know if it's possible to replace Spring.Net's built-in IoC container with Ninject. We use Ninject on my team for IoC in our other projects so I would like to continue using that container if possible.

Is this possible? Has anyone written a Ninject-Spring.Net Adapter??

Edit

I like many parts of the Spring.Net package (the data access, transactions, etc.) but I don't really like the dependency injection container. I would like to replace that with Ninject

Thanks

Deprave

Answer 1

Jeffrey, can you please provide an example of what you are trying to do? I do not see your point, why/where/how you want to mix the 2 containers. If your code is entirely container-agnostic, then you won't have any problems to use either container for doing the wiring.

Turquoise

Erich, I don't want to mix the two, I want to completely replace the Spring.Net container with Ninject (We use it on other projects and I prefer its simple, fluent API). Side question: Is the Spring.Net written around property or constructor injection in general? Some of the classes I have looked at look like they are configured with propery injection. – Deprave

Let me clarify as I see where the misunderstanding is coming from. I like, for instance, the DAOs and ADO.Net wrappers used in Spring.Net but I want to be able to configure those components without using the container provided as part of Spring.Net. – Deprave

Jeffrey, it is perfectly ok to use Spring.NET's other libraries separately from the IoC container. Regarding Constructor- vs. Property injection, Spring.NET allows you to choose between the two per object. When it comes to automatic wiring objects, you can even configure the Spring container to first look for a constructor and - if none is found or can be satisfied - try property injection instead. Regarding the simple fluent API you might want to checkout my new Spring.Config project eeichinger.blogspot.com/2009/12/…. – Turquoise

Thansk Erich. I came across mention of your Spring.Config project when researching Spring.Net, it looks very good! Spring.Net looks very string it was the XML config that was really a downer for me. Thanks – Deprave

Answer 2

I can't talk specifically about converting Spring.NET to Ninject, but in general, all application code should be written to be DI Container-agnostic.

The best way to think about DI Containers is the Hollywood Principle. In DI terms, it becomes, don't call the DI Container, it'll call you.

In other words, the best application of DI is to use simple patterns such as Constructor Injection and Abstract Factory.

Most DI Containers worth their salt inherently understand these patterns, so no special, DI Container-specific, jumping through hoops should be needed.

This also means that ideally, you should only have DI Container-specific code in a single file in your application. This place is called the Composition Root, and this is where the DI Container wires up the entire object graph and gets out of the way.

If you follow this principle, you can easily exchange one DI Container for another.

The following posts have more details:

• Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?)
• Design - Where should objects be registered when using Windsor

Abusive

+1. Agreed - you definitely want to avoid passing around the container for use as a service locator. – Chairborne

I agree with your statements, I just wanted to know if Spring.Net was developed in such a way. I don't have any experience with it and don't want to spend time looking into it if I can't use Ninject with it – Deprave

Answer 3

I meant everything I said in my other answer. However, I also realize that if you currently use Spring.NET as a Service Locator (i.e. you have code sprinkled all over your code base that queries the container), that answer may not be very helpful.

If this is the case, you may find the Common Service Locator project helpful. It is an open source project that attempts to abstract away specific Service Locators, hiding them all behind a common interface.

While they don't seem to have a Ninject implementation, they do have a Spring.NET implementation, so maybe that can take you halfway there.

For the record, I consider Service Locator an anti-pattern, and find that the Common Service Locator is the wrong answer to the wrong problem. In my eyes, it is utterly redundant, but it may be helpful to you as an intermediate step.

Abusive

Hi Mark, I appreciate your very detailed and informative answers but I have the same comment as before: All I really want to know is if someone has used Ninject with Spring.Net and/or what their experience has been, how they wired it up, etc.? – Deprave