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

Question

我不确定它是否只是我,但我感觉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是否是更好的解决方案？

Answer 1

如果对象创建是你的瓶颈,你处于一个非常好的状态(其他一切都像魅力那么<1毫秒的操作计数)或者非常糟糕的一个(你的构造者正在做一些繁重的工作 - 他们不应该这样做至).

Mark Seemann已经在这里讨论了这个主题:http: //blog.ploeh.dk/2011/03/04/Composeobjectgraphswithconfidence/

在许多情况下,你必须采取的性能影响,因为你无论如何都需要这些课程,但有时你可能会担心过早地使用这种性能.但是,我声称在绝大多数情况下,这种担忧是无关紧要的.

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