We have an MVC3 controller in which there is some ‘common’ work that we rolled into the controller constructor. Some of that common work is done by a losely coupled class (say ourService) that’s dynamically resolved through Unity (for IoC / Dependency injection). ourService is null (i.e. not resolved) in the Controller’s constructor BUT it’s properly resolved in the usual Controller methods. The simple demo code below shows the issue:
public class Testing123Controller : BaseController
{
[Dependency]
public IOurService ourService { get; set; }
public Testing123Controller()
{
ourService.SomeWork(1); // ourService=null here !!
...
}
public ActionResult Index()
{
ourService.SomeWork(1); // resolved properly here here !!
...
}
...
}
Question:
- Why is there this different in Unity resolution behavior? I would expect consistent behavior.
- How can I fix it so Unity resolves this even in the controller’s contructor?
The way we’ve setup Unity 2.0 is :
Global.asax
Application_Start()
{
...
Container = new UnityContainer();
UnityBootstrapper.ConfigureContainer(Container);
DependencyResolver.SetResolver(new UnityDependencyResolver(Container));
...
}
public static void ConfigureContainer(UnityContainer container)
{
...
container.RegisterType<IOurService, OurService>();
...
}
IOurService.cs
public interface IOurService
{
bool SomeWork(int anInt);
}
OurService.cs
public class OurService: IOurService
{
public bool SomeWork(int anInt)
{
return ++anInt; //Whew! Time for a break ...
}
}
As a basic principle of classes, before an instance property can be set, the instance has to be instantiated.
Unity needs to set the dependency property, but it can’t do so until the instance has been fully instantiated – i.e. the constructor must have completed executing.
If you are referencing the dependency property in the constructor, then this is too early – there is no way for Unity to have set it yet – and therefore it will be unset (i.e. null).
If you need to use the dependency in the constructor, then you must use constructor injection. Although in general, using constructor injection is usually the better method anyway:
Note: In the example I left
ourServiceas a publicly gettable & settable property in case other parts of your code need to access it. If on the other hand it is only accessed within the class (and had only been made public for Unity purposes), then with the introduction of constructor injection, it would be best to make it aprivate readonlyfield.