asp.net-mvc – 在asp.net mvc控制器中使用构造函数注入的IoC会浪费资源吗？

我不确定它是否仅仅是我,但我感觉ASP.NET MVC控制器中使用的构造函数注入导致不必要的资源消耗.

在创建控制器时,仍然需要创建未用于特定Web请求的组件.当我渴望牛奶时,就像买摊位牛奶和果汁一样,然后我扔掉了果汁.

比较控制器的构造函数注入和服务定位器的这些示例,以澄清我的担忧.

构造函数注入,booth deps已创建,但只使用了一个.

public class MyController : Controller
{
    private readonly IDep1 _dep1;
    private readonly IDep2 _dep2;

    public MyController(IDep1 dep1,IDep2 dep2)
    {
        _dep1 = dep1;
        _dep2 = dep2;
    }

    public ActionResult Index()
    {
        _dep1.MakeStuff();
        return View();
    }
    public ActionResult PageTwo()
    {
        _dep2.MakeStuff();
        return View();
    }
}

服务定位器,每个dep仅在使用时创建.

public class MyController : Controller
{
    public ActionResult Index()
    {
        var dep1 = ServiceLocator.Resolve<IDep1>();
        dep1.MakeStuff();
        return View();
    }
    public ActionResult PageTwo()
    {
        var dep2 = ServiceLocator.Resolve<IDep2>();
        dep2.MakeStuff();
        return View();
    }
}

请注意,IoC容器(由于多种原因有利)仍可用于服务定位器模式.我不希望这是围绕IoC和容器框架的讨论,也不希望构造函数注入的其他好处(清除可靠性依赖性等).这是构造函数注入模式以及它如何浪费我担心的ASP.NET MVC控制器情况中的资源.

我想这里的主要问题是：
对于上述场景(ASP.NET MVC控制器),Service Locator是否是更好的解决方案性能？

解决方法

如果对象创建是你的瓶颈,那么你处于一个非常好的状态(其他一切都像魅力那样< 1 ms操作计数)或者非常糟糕(你的构造者正在做一些繁重的工作 - 他们不是应该). Mark Seemann已经在这里讨论了这个主题：
http://blog.ploeh.dk/2011/03/04/Composeobjectgraphswithconfidence/

In many cases that’s a performance hit you’ll have to take because you
need those classes anyway,but sometimes you might be concerned with
taking this performance hit too early. However,I make the claim that
in the vast majority of cases,this concern is irrelevant.

并提供了一个可能的解决方案,如果它仍然对你很重要(延期分支).

原文地址：https://www.jb51.cc/aspnet/248811.html