它是一个preferred方式注入IUnityContainer本身ASP.NET MVC控制器构造函数中的参数 [英] Is it a preferred approach to inject IUnityContainer itself as an argument inside ASP.NET MVC Controller Constructor

查看:128
本文介绍了它是一个preferred方式注入IUnityContainer本身ASP.NET MVC控制器构造函数中的参数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在asp.net MVC 4使用Unity.Mvc4,并内置引导程序文件中注册的所有类型象下面这样。

 公共静态类引导程序
        {
            公共静态初始化IUnityContainer()
            {
                变种容器= BuildUnityContainer();                DependencyResolver.SetResolver(新UnityDependencyResolver(容器));                返回容器中;
            }
    -----------------------
    ------------------------

在我的控制器构造函数中,我注射IUnityContainer本身调用按需解决(),像下面

 私人IQuestionBusinessLogic _qstnBL; 公共myController的(IUnityContainer unityContainer)
            :基地(unityContainer)        {                     qstnBL = _unityContainer.Resolve< IQuestionBusinessLogic>();
    }

查询是


  1. 是否有通过注入IUnityContainer任何性能负担
    unityContainer本身?

  2. 是否有任何其他的方式来调用比访问解析()的
    IUnityContainer unityContainer这样?

  3. 请打电话到解决()它的自我有任何性能负担?


解决方案

这是一个非常糟糕的方式来结构化类。相反,服务之间作出明确的相关性,你毁了你的班,依赖特定的IoC框架。

在国际奥委会成为您一流的设计中不可或缺的一部分。取而代之的是看不见的帮手就成了一等公民。

相反,你应该让你的类取决于你的其他类:

 公共myController的(IQuestionBusinessLogic questionBusinessLogic)
        :基地()
{
}

和让特定的依赖解析器满足你的依赖。这样你摆脱了IOC依赖基础设施。具体来说,依赖解析器是在成分根定义您的应用程序(最有可能的解决方案的主要项目)的一部分,它是一个的唯一一类胶水你的类具体的IoC。

一个使用的IoC框架中的黄金法则,如果没有IoC框架设计类和依赖。然后,推出一款只有帮你,不是让你依赖于它。

I am using Unity.Mvc4 in asp.net MVC 4 and have built-in Bootstrapper file to register all types like below.

   public static class Bootstrapper
        {
            public static IUnityContainer Initialise()
            {
                var container = BuildUnityContainer();

                DependencyResolver.SetResolver(new UnityDependencyResolver(container));

                return container;
            }
    -----------------------
    ------------------------

In my Controller constructor, I am injecting IUnityContainer itself for calling Resolve() on demand, like below

 private IQuestionBusinessLogic _qstnBL;

 public MyController(IUnityContainer unityContainer)
            : base(unityContainer)

        {   

                     qstnBL = _unityContainer.Resolve<IQuestionBusinessLogic>();
    }

Queries are

  1. Is there any performance burden by injecting IUnityContainer unityContainer itself?
  2. Is there any other way to call Resolve() than access the IUnityContainer unityContainer this way?
  3. Make a call to Resolve() it self has any performance burden?

解决方案

That's a really bad approach to architecture your classes. Instead of making explicit dependencies between services, you spoil your classes with dependencies to specific IoC framework.

The IoC becomes an integral part of your class design. Instead of being an "invisible helper" it becomes a first class citizen.

Instead, you should make your classes depend on your other classes:

public MyController( IQuestionBusinessLogic questionBusinessLogic )
        : base()
{   
}

and let the specific dependency resolver satisfy your dependencies. This way you free your infrastructure from the IoC dependency. Specifically, the dependency resolver is defined in the Composition Root part of your application (most probably the main project of the solution) and it is the only class that glues your classes to the specific IoC.

One of golden rules of using the IoC frameworks is "Design your classes and dependencies as if there was no IoC framework. Then, introduce one only to help you, not to make you dependant on it".

这篇关于它是一个preferred方式注入IUnityContainer本身ASP.NET MVC控制器构造函数中的参数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆