开发者

Should creating a Unity Container be considered an expensive operation as it relates to resources and time?

开发者 https://www.devze.com 2023-04-05 03:00 出处:网络
I\'ve recently started using Unity for dependency injections in .net. I was under the impression that a Unity Container would开发者_运维百科 most likely be a singleton or static member of a class. I s

I've recently started using Unity for dependency injections in .net. I was under the impression that a Unity Container would开发者_运维百科 most likely be a singleton or static member of a class. I saw another developer using it in a request handler that will receive a lot of traffic.

Is there some magic happening that keeps the cost low for creating a new Unity Container every time, or should this code be re-factored to only create the Unity container once?

This code is part of the implementing class of a .svc Service.

public string DoSomeWork(Request request)
{
   var container = new UnityContainer().LoadConfiguration("MyContainer");
   var handler = container.Resolve<RequestHandler>();
   return handler.Handle(request);
}


Not 100% sure with Unity, but with most IoC containers, the creation of the container and especially the loading of container configuration is a reasonably expensive operation.

I have to question why this developer is utilizing the container in this manner however. Ideally the IoC container shouldn't even be a static or singleton object - it should be instantiated only to resolve the top level object of your dependency tree, and the rest of the objects in your application should be constructed automatically through dependency injection. In the case of your example, the class containing that method ideally would have the RequestHandler (ideally an interface of this) injected into it through the constructor so that class does not need to know about the IoC container.


This is not the right way to use an IOC container - basically your are using it as a service locator, but this will cause dependencies to the IOC container to be sprinkled all over the code base.

What you should do is have one central spot in your codebase where all dependencies are resolved and then use dependency injection (DI) to propagate the resolved concrete classes down the chain, i.e via constructor injection. So your class really should look something like this:

public class Foo
{
    private readonly IRequestHandler _handler;

    public Foo(IRequestHandler handler)
    {
        _handler = handler;
    }

    public string DoSomeWork(Request request)
    {
        return _handler.Handle(request);
    }
}
0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号