When boiled down, the main difference is that IoC containers are generally most useful with static dependencies (known at compile-time), and MEF is generally most useful with dynamic dependencies (known only at run-time). As such, they are both composition engines, but the emphasis is very different for each pattern. Design decisions thus vary wildly, as … Read more
For dependencies that are independent of the instance you’re creating, inject them into the factory and store them until needed. For dependencies that are independent of the context of creation but need to be recreated for each created instance, inject factories into the factory and store them. For dependencies that are dependent on the context … Read more
In the example below you have an interface implemented twice and injected on demand into two different client classes, just as you request. The trick is to use named registrations. class Program { static void Main(string[] args) { IUnityContainer container = new UnityContainer(); container.RegisterType<IFoo, Foo1>(“Foo1”); container.RegisterType<IFoo, Foo2>(“Foo2”); container.RegisterType<Client1>( new InjectionConstructor(new ResolvedParameter<IFoo>(“Foo1”))); container.RegisterType<Client2>( new InjectionConstructor(new ResolvedParameter<IFoo>(“Foo2”))); … Read more
See here and here for a pretty thorough technical comparison of several IoC containers, although somewhat outdated by now (they’re from before Windsor 2.0) However, I don’t think there are really any vital features that Windsor offers and other containers don’t. Windsor, StructureMap, Spring.NET have all been around for several years and have been used … Read more
You can configure dependencies with or without names in the API, attributes, or via the config file. You didn’t mention XML above, so I’ll assume you’re using the API. To tell the container to resolve a named dependency, you’ll need to use an InjectionParameter object. For your ClientModel example, do this: container.RegisterType<IClientModel, ClientModel>( new InjectionConstructor( … Read more
I am preparing a presentation for a usergroup. As such I just went through a bunch of them. Namely: AutoFac, MEF, Ninject, Spring.Net, StructureMap, Unity, and Windsor. I wanted to show off the 90% case (constructor injection, which is mainly what people use an IOC for anyway). You can check out the solution here (VS2008) … Read more
As a general consideration, circular dependencies indicate a design flaw – I think I can safely say this since you are not the original author of the code 🙂 I wouldn’t consider an Initialize method a good solution. Unless you are dealing with an add-in scenario (which you aren’t), Method Injection is not the right … Read more
The Per Thread Lifetime is a very dangerous lifestyle and in general you should not use it in your application, especially web applications. This lifestyle should be considered dangerous, because it is very hard to predict what the actual lifespan of a thread is. When you create and start a thread using new Thread().Start(), you’ll … Read more
You definitely do not want to call Dispose() on an object that was injected into your class. You can’t make the assumption that you are the only consumer. Your best bet is to wrap your unmanaged object in some managed interface: public class ManagedFileReader : IManagedFileReader { public string Read(string path) { using (StreamReader reader … Read more
As of today they have added this functionality: It’s in the latest drop here: http://unity.codeplex.com/SourceControl/changeset/view/33899 Discussion on it here: http://unity.codeplex.com/Thread/View.aspx?ThreadId=66434 Example: container.Resolve<IFoo>(new ParameterOverrides<Foo> { { “name”, “bar” }, { “address”, 42 } });”