CODEWITHSUNDEEP
asp.net-mvcasp.net-mvc-3dependency-injectionunity-container
Antony Blazer
Antony Blazer

Reputation: 705

ASP.NET MVC3 Dependency Injection misunderstanding

public object GetService(Type serviceType)
{
    object resolvedObject = null;
    try
    {
        resolvedObject = _unityContainer.Resolve(serviceType);
    }
    catch(ResolutionFailedException e) { }

    return resolvedObject;
}

Is this best practice to catch exception and return null? By default mvc try to resolve IControllerFactory and IViewPageActivator, i.e. i get two catched exceptions. I don't prefer this solution.

My friend suggest to check serviceType on IControllerFactory, IViewPageActivator and if an exception is raised - catch and logged error. but as for me - it is not best solution, it like kind of hardcode.

Upvotes: 1

Views: 1010

Answers (3)

Stan Bashtavenko
Stan Bashtavenko

Reputation: 1095

For IControllerFactory you can

.RegisterType<IControllerFactory, DefaultControllerFactory>()

I am not sure which classes implement IViewPageActivator and ModelMetadataProvider. Event though an exception can be swallowed, supressing exceptions it is not a good practice simply because in general exceptions affect performance. Once an exception is caought the framework populates stack trace which take time.

Upvotes: 0

Kazi Manzur Rashid
Kazi Manzur Rashid

Reputation: 1544

This obviously not a best practice, But ASP.NET MVC is implemented in way that when the IoC is not able to resolve a service it should return null, so that the mvc framework can fallback to its default. Pls note there are number of services other than controller/view factory depends on it, so throwing exception will break those from functioning.

I argued with the design decision in the internal asp.net mailing list, but this how it currently stands :-(.

Upvotes: 0

Matthew Abbott
Matthew Abbott

Reputation: 61579

MVC3's DependencyResolver is a service locator, first and foremost. It is essentially the lovechild of MVC and the Common Service Locator (commonservicelocator.codeplex.com). The differences between a CSL service locator and MVC3's DependencyResolver is that the MVC architects decided that they needed a safer way of handling cases where services cannot be resolved through it, and the answer they chose was that the implementation of IDependencyResolver should return null in these circumstances.

With CSL implementations of IServiceLocator, the standard practice is to throw an ActivationException which allows for a standardised exception for handling these cases.

With MVC, the framework will call the DependencyResolver to try and resolve a configured service. If it cannot find a suitable service, it uses a default.

E.g., when it wants to find an IControllerFactory, it will check the DependencyResolver first. If it fails there, it will use the DefaultControllerFactory configured through ControllerBuilder.SetControllerFactory(...). Because of this check-first approach, it's better to return null then let a container specific exception bubble up.

This means that you must catch/swallow any exception at this point, as it is not MVC framework's responsibility to handle it for you (the onus should be on the container/IDependencyResolver itself).

You could log this at this stage, but the practice with MVC3 is to return null in these instances.

Upvotes: 5

Related Questions