Yes do not share context and use one context per request. You can also check linked questions in that post to see all problems which a shared context caused. Now about Unity. Idea of PerCallContextLifetimeManager works but I think provided implementation will not work for more than one object. You should use PerHttpRequestLifetimeManager directly: public … 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
It’s not the same. if(controllerType is IController) would always evaluate to false since controllerType is always a Type, and a Type is never an IController. The is operator is used to check whether an instance is compatible to a given type. The IsAssignableFrom method is used to check whether a Type is compatible with a … Read more
The main difference is that with unity you will explicitly register each class you want to use in the composition: var container = new UnityContainer(); container.RegisterType<IFoo,Foo>(); container.RegisterType<IBar,Bar>(); … var program = container.Resolve<Program>(); program.Run(); In MEF on the other hand, you mark classes with attributes instead of registering them somewhere else: [Export(typeof(IFoo))] public Foo { … … Read more
I’m sure there’s a lot of ways code could call SynchronizedLifetimeManager, or a descendant like ContainerControlledLifetimeManager, but there were two scenarios in particular that were causing me problems. The first was my own fault – I was using constructor injection to supply a reference to the container, and in that constructor I was also adding … Read more
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
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 had the same problem and found the “fix” looking at Prism sample code files. Looks like, even if it is not a dll in Unity V2 you have to add a reference in your class to: Microsoft.Practices.Unity my complete “using” section is as follow using System; using System.Windows; using Microsoft.Practices.Composite.Modularity; using Microsoft.Practices.Unity; using Microsoft.Practices.Composite.UnityExtensions; … Read more
Figured it out. For ApiControllers, MVC 4 uses a System.Web.Http.Dispatcher.IHttpControllerFactory and System.Web.Http.Dispatcher.IHttpControllerActivator to create the controllers. If there is no static method to register what the implementation of these they are; when they are resolved, the mvc framework looks for the implementations in the dependency resolver, and if they are not found, uses the default … 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 } });”