依赖注入抽象库答案

【问题标题】：Dependency Injection Abstraction Library依赖注入抽象库
【发布时间】：2016-09-02 14:46:48
【问题描述】：

有没有类似的 https://github.com/aspnet/DependencyInjection 适合旧的 .NET 框架应用程序？

“包含 ASP.NET Core 和 Entity Framework Core 使用的常见 DI 抽象。”

我正在编写一个框架，我不想强制用户使用特定的 IoC 容器。

【问题讨论】：

您可以使用使用 DI 包的.NET Core 项目，然后让该项目以整个框架为目标。
我要试试这个。您能否更改您的评论以回答，以便如果我设法使其工作，我可以接受它？在将这样的项目添加到现有的 4.6.2 解决方案中时，我还可以使用一些帮助。
完全阻止common DI abstraction；制作你的框架DI friendly.
@Steven，感谢您的评论。我读了那篇文章，我知道那将是“正式正确”的方式。然而，我在生产力和正确性之间划清界限，并愿意追求前者。我还认为 ASP.NET vNext 使用 DI 抽象，并且我想为使用该技术的任何人（包括我自己）提供熟悉的体验。我的框架是一个基于约定的应用程序服务器，它应该公开基于队列和基于 http 的端点，而不需要对开发人员强制使用特定技术。
@Raine：当然。这是维护者和微软之间的this discussion。

标签： c# .net dependency-injection asp.net-core

【解决方案1】：

我正在编写一个框架，我不想强制用户使用特定的 IoC 容器。

这样做的方法是创建好的扩展点供用户替换。拥有一个通用的 DI 抽象是个坏主意，因为这是一个名为 Conforming Container 的反模式。这种反模式不是理论上的东西。 ASP.NET Core 应用了这种反模式，其结果是 Simple Injector 维护者和 Autofac 维护者都无法创建完全符合定义合同的适配器实现。可以阅读 here 和 here 的 Simple Injector 故事，可以在 here 找到与 Microsoft 的一般讨论。您可以在此线程 here 中阅读我给 Microsoft 的公开信，并且您可以看到 Autofac 维护人员 agree 带有此声明。

最后，微软acknowledged 承诺他们将通过提供良好的集成可能性来解决问题

每个框架都有足够的组合根，以使集成尽可能顺利。

因此，请避免在您自己的框架中应用 Conforming Container 反模式。我们已经看到微软在 ASP.NET Core 的下一个次要版本中修复了这种反模式导致的问题。而是像 Mark Seemann 所描述的那样提供“良好的集成可能性”here。

【讨论】：

感谢您抽出宝贵时间，史蒂文。鉴于 asp.net core 和 .net core 的明显不确定性（开发方面）的状态，我最好还是谨慎行事，而不是模仿当前的 asp.net core 版本。我也可以欣赏您提供的文章中的优点。我仍然不确定在这种特定情况下如何平衡生产力与正确性，但我想这与领土有关:)

【解决方案2】：

您可以使用使用 DI 包的.NET Core 项目，然后让该项目以完整框架为目标。您将定位“完整”目标框架名字对象 (TFM) 之一，而您的 project.json 看起来像这样：

{      
  "dependencies": {
    "Microsoft.Extensions.DependencyInjection": "1.0.0"
  },

  "frameworks": {
    "net46": { }
  },

  "version": "1.0.0-*"
}

【讨论】：

尝试了一些组合和一些重构，但在 .NET 4.6.2 解决方案中拥有 .net 核心库似乎并不容易。不过可能是我！