【问题标题】:Controller dependency injection without Unity没有 Unity 的控制器依赖注入
【发布时间】:2017-11-30 17:58:51
【问题描述】:

我有一个不知道如何解决的问题。我有一个容器,其中包含我使用 WebApi 公开的不同服务的不同接口。问题是我需要在我的控制器中获取该依赖项,并且我必须避免使用静态。我读到了这个

http://beletsky.net/2011/10/inside-aspnet-mvc-idependencyresolver.html

http://www.asp.net/web-api/overview/advanced/dependency-injection

在 asp.net 中,我读到我可以实现自己的 IDependencyResolver。这是疯了吗?因为我搜索了很多,我只找到了使用 Unity 的示例。如果我不想使用那个依赖注入器?实现这一目标的最佳方法是什么?

public class MyController: ApiController
{
    private InterfaceService m_interfaceService; //This is the dependency I need

    public MyController()
    {

    }

    [HttpGet]
    [Route("myServices/")]
    public List<IServiceCategory> GetServiceObjectsList()
    {
        return m_interfaceServices.GetObjectsList();
    }

}

【问题讨论】:

  • 不喜欢unity就不要用,但是不要自己写DI容器。
  • 那我该怎么办?具有不同接口的容器是我团队制作的“某种”DI。这就是为什么我不能使用像 Unity 这样的 DI 的原因
  • @RobertMoskal 为什么不建议编写自己的 DI 容器?
  • 专注于解决您的领域问题!
  • 既然已经有一堆好的 DI-Container,为什么还要写一个 DI-Container?我一遍又一遍地进行同样的讨论。 “让我们编写自己的日程安排应用程序”。 “不,让我们使用 Quartz.Net”。 “让我们编写自己的消息服务总线”..“不,让我们使用 RabbitMQ 或 Azure-Message-Bus”。同样的对话,一遍又一遍。

标签: c# asp.net asp.net-mvc asp.net-web-api


【解决方案1】:

所以你有一个预先存在的容器/依赖机制!您应该询问您的团队,为什么制作这样的东西而不是使用 .net 世界中所有的好东西是个好主意。

尽管如此,来自文档:

http://www.asp.net/web-api/overview/advanced/dependency-injection

虽然你可以编写一个完整的 IDependencyResolver 实现 从头开始,界面真的被设计为充当桥梁 在 Web API 和现有 IoC 容器之间。

该页面上的 Unity 示例显示了必须采取哪些措施来弥合 Unity DI 框架和 web mvc 之间的差距。你只需要对你的自制卷做同样的事情。只需实现几个方法即可。加油!

【讨论】:

  • 感谢您的回复。关于这个的主要问题可能是我不会拥有这个 DI 提供给我们的所有配置部分。
  • 不过你还是要试试!祝你好运!
【解决方案2】:

这是一个满足您要求的实现:

namespace AdvancedDI.Controllers
{
    public class ProductController : ApiController
    {
        public IFactory iFactory { get; set; }

        protected override void Initialize(HttpControllerContext controllerContext)
        {
            DIAPP.GetContainer(this);
            base.Initialize(controllerContext);
        }

        public IHttpActionResult Get()
        {
            var response = iFactory.DoWork();
            return Ok(response);
        }

        protected override void Dispose(bool disposing)
        {
            DIAPP.Dispose(this);
            base.Dispose(disposing);
        }
    }
}

这是一种基于属性的注入。 UnityContainerExtensions 是可能的。 Initialize 方法将在 Get 之前被调用。

第 1 步。DIAPP.GetContainer(this) 承载整个 productController 上下文。

第 2 步。GetContainer 从中接收 IFactory 属性信息。

第 3 步。接下来,您有机会收到IBuilderContext 的统一IFactory

【讨论】:

  • 请解释这段代码的工作原理和作用。
  • 这是一种基于属性的注入。 UnityContainerExtensions 可以实现。 Initialize 方法将在 Get 之前调用。第 1 步:DIAPP.GetContainer(this) 携带整个 productController 上下文。第 2 步:GetContainer 从此接收“IFactory”属性信息。第 3 步:接下来您将有机会收到此 IFactory 的统一 IBuilderContext。(请参阅有关 (UnityContainerExtensions) 的更多信息
【解决方案3】:

我使用 Ninject 和 AutoFac 进行依赖注入。这不是疯狂,而是常见的做法。

【讨论】:

  • 我的意思是如果我实现 IDependencyResolver。这是个坏主意吗?因为我们的容器在某种程度上是一个“依赖注入器”,我们不能包含第三个。
  • 不要构建依赖解析器,使用预构建的(即我列出的)。
  • 根本不要使用 IDependencyResolver。使用 IHttpControllerActivator。见blog.ploeh.dk/2012/10/03/…
猜你喜欢
  • 2018-10-21
  • 1970-01-01
  • 2016-02-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-12-26
  • 2015-12-10
相关资源
最近更新 更多