I've been using Castle Windsor in my previous project and I liked it a lot. For my current project I'm looking to use a different IoC container. Castle Windsor hasn't had any new releases since 2007 and is still not at version 1.0 so it is hard to justify using it in a commercial environment.
One of the things I like about Castle Windsor is that you can have the container call an Initialize method on your services after all dependencies have been set simply by making the service implement IInitializable. I used this a lot. It makes it easy to do property injection instead of constructor injection and that cleans up code and tests quite a bit.
I've been looking at StructureMap, AutoFac, Unity and Spring.Net as alternatives but of these only Spring.Net supports something similar, it automatically calls an Init() method. Unfortunately Spring.Net does not really support the way I want to work with an IoC container (it injects based on string keys instead of interface declarations and therefore its autowiring support is limited too)
Did I miss a similar feature in the IoC containers I looked at? Is my way of working with IoC containers wrong somehow? Or are there other IoC containers that do support something like IInitializable or Init()?
Autofac can do it - they call it Startable
With StructureMap, you could do something like this:
ForRequestedType<IFoo>()
.TheDefaultIsConcreteType<Foo>()
.OnCreation(x => x.Init());
It's not as easy as implementing an 'Initialisation' interface on your class, but it also means you don't need to tie your class implementation to your choice of DI container by inheriting from a DI container specific interface (although I'm not sure how much of an issue that is in reality).
I believe that constructor injection is far more commonly used right now, and property injection is widely seen as a fallback for cases where it is not feasible to get the DI Container to perform object construction for you (e.g. ASP.NET webforms). I could be wrong there though, that's just my view on the subject!
Do you really think that property injection "cleans up code and tests quite a bit"? That's interesting because I sort of think the opposite - I think constructor injection is 'cleaner', and I'm guessing that could be simply because that's how I normally do it so that's what I'm used to. :)
Castle may not have had any release in some time, but it's still actively developed. You can get latest (pretty stable) builds here.
There also is going to be an official v2.0 release quite soon. Why not use what you already know, if you know that it's good?
LinFu.IOC has it--it's called IInitialize. You can find it here: github.com/philiplaureano/LinFu
Related
I noticed that most DI frameworks use the constructor approach, but some support also setting dependencies through properties. How does Kephas regard this problem and what built-in means are provided for that? Disclaimer: I think about supporting Autofac, but this depends on my spare time. I saw that something was started in this direction in Kephas, but this seems at the very beginning.
At this point, Kephas is dependent on which DI container you choose. If you are talking about Autofac (as well as MEF/System.Composition), it supports both constructor and property injection. All Kephas service implementation use exclusively the constructor injection, with the notable exception of the Logger property. This is by design, as to inject it through constructor seemed not very nice.
I am going to use it in a project with less-experienced developers so a complex framework such as Spring.NET is not an option. I was thinking about:
Ninject
Castle Windsor
StructureMap
Which would present a moderate learning curve without losing flexibility?
and another question - where is the correct place to put the configuration? Since the kernel/configuration on a 3-tier ASP.NET application (not MVC!!! all examples are using MVC :) )
The great thing about proper use of DI is that you can defer the decision about which DI Container to use until the last responsible moment. In application architecture terms, this corresponds to a so-called Composition Root, which is where you wire all depedendencies together. This is often the application's entry point.
Apart from the Composition Root, the entire application can be written without referencing any particular DI Container at all. You just need to follow well-known patterns and principles.
When it comes to pick a DI Container, I'm aware of these DI Containers for .NET:
Castle Windsor
StructureMap
Unity
Autofac
Ninject
Spring.NET
Personally, I have been happy with Castle Windsor so far, but I have yet to gain extensive experience with all of these containers.
Here's an ASP.NET (not MVC) Ninject sample:
http://davidhayden.com/blog/dave/archive/2008/06/20/NinjectDependencyInjectionASPNETWebPagesSample.aspx
I have used ninject and found it easy to bring new developers up to speed with it.
Consider to start with wiring by hand: see http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion . It gives less-experienced developers a better insight in the basics of IOC/DI.
I think you are being too hasty to reject spring.net. Spring offers an extremely flexible learning curve, so at the beginning it's kind of "you take what you want from it" approach.
You can start with the simplest-of-all IoC container, and later on move to aop, transactions, unit testing, or whatever you desire, so the complexity builds up gradually.
This was the #1 selling point at my last two jobs for using Spring. Additional points were:
It doesn't force you to use its api or to bend your architecture. Again, this leads you to adapt its features at your own pace.
Very extensive documentation.
When the project matures, so will your developers, so spring will come out handy at the end ... (at no cost in the beginning, in my opinion)
Autofac is my container of choice. It allows registration via lambda expressions for maximum flexibility (the link has some nice examples).
It also has a Silverlight-compatible version. I'm unsure if the other containers do.
As for placement, the container should be built during application startup. For an ASP.NET application, this would be in the Global.Application_Start method.
Autofac has ASP.NET integration which injects pages instances using the container you build during startup.
Have a look at http://funq.codeplex.com/ first of all it's extremely fast compared to windsor and other reflection based containers second of all it's very flexible but still has a very readable configuration (If you've gotten your head around Lamba expressions which should take to long any ways)
We use the managed extensibility framework. It is part of the .NET 4.0 framework (currently in release candidate), where you can find it in the System.ComponentModel.Composition namespace. The codeplex site is currently still the best source of documentation.
The focus of MEF is more on "extensibility" rather than "dependency injection", but it uses dependency injection to achieve this. For example, the visual studio 2010 code editor uses MEF to enable extensibility.
We use it as a DI framework and have not yet run into any problems (though I did need the dynamic instantiation sample which is not part of the core yet).
If you're yet familiar with any DI framework, I'd go with the Simple Injector.
It has a very simple API, that will get you started very quickly. Although simple, it still enables many advanced configuration scenario's. The library designed with migration in mind, which means that switching to another framework would is rather straightforward. To prove this point, there is an migration guide on the project's wiki.
In addition to Ninject, which is a great product, there are also two other options that I'm familiar with:
Microsoft's Unity. Some Alt.NET folks think it's a little on the big & complicated side. I've been using it for several months now as part of Prism (Prism is NOT required to use Unity. It's available stand-alone) and I've found it to be simple and straight-forward.
StructureMap. I've found StructureMap to also have a very gentle learning curve with fast ramp up.
Hope this helps.
I find StructureMap very usefull and intuitive to use. I played with Ninject a bit and found that less convenient, but YMMV. I would also recommend you use the common service locator as an intermediary between the actual implementation of your IOC and your application. When you want to switch your IOC/DI container later on, this is less painfull. There are adapters for StructureMap and Castle windsor. And I think from googling that there also is an adapter for Ninject 2 according to this blog.
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
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
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.
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.
I have a solution with two relevant (to this question) projects, and a few others;
Class library with functionality used by several other projects.
ASP.NET MVC application.
My question is basically where I should do IoC with Ninject 2, considering...
The class library needs some DI love, among other things in the repository classes which need web request specific session objects (think Unit of Work).
The MVC app needs DI since with Ninject 2 you basically inherit from NinjectHttpApplication.
Unit tests for the class library need to be aware of this to inject a different set of repositories.
Unit tests for the web app need to be injected for the same reason.
I have painted myself into a mental corner here, because I only saw three options to begin with. DI in the class library, DI in the web app, or both, but there are problems with each:
I can't do DI only in the class library since the MVC app needs to inherit from NinjectHttpApplication to begin with.
I can't do DI only in the MVC app - the class library is used by other libraries, after all, and the MVC app shouldn't know too much about the internals of the library anyway.
I guess this is the only way out I can see: Independent IoC for both projects. The class library and the MVC app each have their own IoC setup and do DI for their stuff without really caring about each other.
Does anyone have some "best practices" or guidelines on how to do something like this? I can't imagine I'm the first person to end up in this situation, and it would sure be nice to know what the "proper" way to do this is...
Thanks!
I don't know NInject, but unless it works vastly different than Windsor, StructureMap etc. the answers tend to stay the same, as there are some common DI patterns. With that in mind:
The first thing to realize is that DI isn't tied to a particular framework such as NInject or Windsor. It is a set of techniques and design patterns to follow. You can do DI manually using so-called Poor Man's DI, but obviously it gets much better with a DI Container.
Why is this relevant? It is relevant because once you realize this, the corollary is that the vast majority of your application's code should have no knowledge of the DI Container whatsover.
So where do you use the DI Container? It should only be used in a Composition Root, which in your case would correspond to Global.asax. You can read a bit more about this in this SO answer - although that question is about Windsor, the principle remains the same.
How about your unit tests then? They should be completely ignorant of the DI Container as well. See this other SO answer for more details.
DI can be achieved in your library with copious use of Constructor Injection. You don't need to reference any DI Container to do that, but it makes life a lot easier if you use a DI Container to resolve all dependencies from the Composition Root.
I absolutely need to use an IoC container for decoupling dependencies in an ever increasingly complex system of enterprise services. The issue I am facing is one related to configuration (a.k.a. registration). We currently have 4 different environments -- development to production and in between. These environments have numerous configurations that slightly vary from environment to environment; however, in all cases that I can currently think of, dependencies between components do not differ from environment to environment, though I could have missed something and/or this could obviously change.
So, the ultimate question is, does anybody have a similar experience using an IoC framework? Or, can anybody recommend one framework over another that would provide flexible registration be it through some sort of convention or simplified configuration information? Would I still be able to benefit from a fluent interface or am I stuck with XML -- I'd like to avoid XML-hell.
Edit: This is a .Net environment and I have been looking at Windsor, Ninject and Autofac. They all seem to now support both methods of registration (fluent and XML), though Autofac's support for lambda expressions seems to be a little different than the others. Anybody use that in a similar multi-deployment environment?
If you want to abstract your container, and be able to use different ones, look into having it injectable in a way I tried to do it here
I use Ninject. I like the fact that I don't have to use Xml to configure the dependencies. I can just use straight up C# code. There are multiple ways of doing it also. I know other libraries have that feature, but Ninject offers fast instantiation, it is pretty lightweight, it has conditional binding, supports compact framework, and it supports Silverlight, 2.0. I also use a wrapper on top of it, in case I do switch it out for another framework in the future. You should definitely try Ninject when deciding on a framework.
I'm not sure whether it will suit your particular case, you didn't mention what platform you're working in, but I've had great success with Castle Windsor's IOC framework. The dependencies are setup in the config file (it's a .NET framework)
Look at Ayendes rhino commons. He uses an abstraction over the IoC container. So that you can switch containers whenever you want. Something like container.Resolve is always there in every container.
I use Structuremap to do the dirty work it has a fluent interface and the XML things and it is powerfull enough for most things you want to do. Each one has it's own pros and cons so a little abstraction so you can easily switch (you never know how long they are going to be around) is good. For the rest I think Spring.Net, Castle windsor, Ninject and StructureMap aren't that far apart anymore.