Question

I thought of applying Dependency Injection and use Unity in the Project I am working on now. Registered the types in Application_Start event of Global.asax file and kept the Unity Conatiner in Application object global variable. However before resolving the presenter instance I need to pass the current webform’s instance as a constructor parameter to the presenter. I am doing this in OnInit event of the page.

protected override void OnInit(EventArgs e)
{
    IUnityContainer container = (IUnityContainer)
        HttpContext.Current.Application["container"];

    container.RegisterInstance<IAddRoleView>(this, 
        new ExternallyControlledLifetimeManager());

    _presenter = container.Resolve<AddRolePresenter>();
    base.OnInit(e);
}

My questions here are:

1. What will happen to the AddRoleView instance once the Request is
   served?
2. Will it be Garbage Collected or will the Unity container always
   keep a reference until application shutdown, as the Unity Conatiner
   instance has been kept in an application object?

Answer 1

What you are doing will not work. You are registering the page instance as singleton in the container. This will not work. Depending on how Unity is built, it will either throw an exception the second time you call RegisterInstance<IAddRoleView>, cache all registered instances forever, or replace the previous implementation. But even if it replaces the previous registration, you have a concurrency bug in your code, since it is possible for a different page to be injected in the AddRolePreventer that is resolved for this Page instance.

I understand what you are trying to achieve. Yyou want to resolve the AddRolePresenter, and want to inject the page into the presenter’s constructor. You made both types dependent on each other through their constructor, which causes a cyclic dependency. You need to break this dependency cycle by injecting the page into a property on the presenter. But don’t let Unity inject the page into the constructor; do this manually:

_presenter = container.Resolve<AddRolePresenter>();
_presenter.View = this;

Some tips:

• Prevent doing any registrations after the initialization phase (after your Application_Start ran). Adding registrations after the initialization phase is typically considered bad practice, since it makes the configuration brittle, and hard to maintain.
• Move this page initialization where you resolve the presenter to the constructor of the page. This allows you to more easily verify whether page’s can be created and do this during starting up your application (or even inside a unit test). Take a look for instance here to see an example of how to do this (it’s documentation of another DI framework, but it will work with Unity as well).
• Prevent storing the container inside the HttpContext.Application dictionary. This makes it too easy to use the container at wrong places, and couples your application too much with Unity. This prevents you from doing refactorings or change Unity for another framework (what you most definitely be doing in the future). Again take a look at this example. It also shows a better way of integrating your container with Web Forms