更新 09.08.2018
Unity正在开发中here https://github.com/unitycontainer/container但我还没有时间测试它如何与 ASP.NET Core 框架配合使用。
更新 15.03.2018
此解决方案针对在使用 .NET Framework 4.5.2 时将 ASP.NET Core v1 与 Unity 结合使用的特定问题NOT.NET 核心框架。我必须使用此设置，因为我需要一些 .Net 4.5.2 DLL，但对于任何重新开始的人，我不会推荐此方法。而且 Unity 没有进一步开发（据我所知），因此我建议在新项目中使用 Autofac 框架。看到这个Post https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection#replacing-the-default-services-container有关如何执行此操作的更多信息。
Intro
我正在使用 ASP.NET 和 MVC 构建 Web 应用程序。此应用程序依赖于某些服务（WCF 服务、数据存储服务等）。现在，为了保持良好的状态和解耦，我想使用 DI（依赖注入）框架，特别是 Unity。
初步研究
我找到了这个博客文章 http://www.global-webnet.com/blog/post/2015/08/24/Dependency-Injection-in-ASPNET-vNext-(adding-Unity-container).aspx但遗憾的是它不起作用。不过这个主意不错。
它基本上是说，您不应该将 ServiceCollection 中注册的所有服务注册到您自己的容器中，而应该引用默认的 ServiceProvider。
所以。如果需要解决某些问题，则会调用默认的 ServiceProvider，如果没有解决方案，则将使用您的自定义 UnityContainer 来解决类型问题。
问题
MVC 总是尝试使用默认的 ServiceProvider 来解析 Controller。
另外，我注意到即使控制器能够正确解析，我也永远无法“混合”依赖项。现在，如果我想使用我的服务之一，但也想使用 ASP 的 IOptions 接口，则该类永远无法解析，因为这两个容器中没有一个具有这两种类型的解析。
我需要的
因此，回顾一下我需要以下内容：
EDIT:
那么问题是我怎样才能实现这些目标呢？
Environment
project.json:
因此，经过一些研究，我针对我的问题提出了以下解决方案：
将 Unity 与 ASP 结合使用
为了能够将 Unity 与 ASP 结合使用，我需要一个自定义 IServiceProvider (ASP 文档 https://docs.asp.net/en/latest/fundamentals/dependency-injection.html#replacing-the-default-services-container）所以我为 IUnityContainer 编写了一个包装器，如下所示
public class UnityServiceProvider : IServiceProvider
{
private IUnityContainer _container;
public IUnityContainer UnityContainer => _container;
public UnityServiceProvider()
{
_container = new UnityContainer();
}
#region Implementation of IServiceProvider
/// <summary>Gets the service object of the specified type.</summary>
/// <returns>A service object of type <paramref name="serviceType" />.-or- null if there is no service object of type <paramref name="serviceType" />.</returns>
/// <param name="serviceType">An object that specifies the type of service object to get. </param>
public object GetService(Type serviceType)
{
//Delegates the GetService to the Containers Resolve method
return _container.Resolve(serviceType);
}
#endregion
}
此外，我还必须更改 Startup 类中的ConfigureServices 方法的签名：
public void ConfigureServices(IServiceCollection services)
to this:
public IServiceProvider ConfigureServices(IServiceCollection services)
现在我可以返回我的自定义 IServiceProvider，并且将使用它将代替默认的 IServiceProvider。
完整的配置服务方法显示在底部的连接部分。
解析控制器
我发现这篇博文 https://simpleinjector.org/blog/2016/07/working-around-the-asp-net-core-di-abstraction/。从中我了解到 MVC 使用 IControllerActivator 接口来处理控制器实例化。所以我自己写了一个，看起来像这样：
public class UnityControllerActivator : IControllerActivator
{
private IUnityContainer _unityContainer;
public UnityControllerActivator(IUnityContainer container)
{
_unityContainer = container;
}
#region Implementation of IControllerActivator
public object Create(ControllerContext context)
{
return _unityContainer.Resolve(context.ActionDescriptor.ControllerTypeInfo.AsType());
}
public void Release(ControllerContext context, object controller)
{
//ignored
}
#endregion
}
现在，如果激活一个 Controller 类，它将使用我的 UnityContainer 进行实例化。因此我的 Unity 容器必须知道如何解析任何控制器！
下一个问题：使用默认的 IServiceProvider
现在，如果我在 ASP.NET 中注册 Mvc 等服务，我通常会这样做：
services.AddMvc();
现在，如果我使用 UnityContainer，则所有 MVC 依赖项都无法解析，因为它们未注册。所以我可以注册它们（如 AutoFac），也可以创建一个 UnityContainerExtension。我选择了扩展并提出了以下两个类：
UnityFallbackProvider扩展
public class UnityFallbackProviderExtension : UnityContainerExtension
{
#region Const
///Used for Resolving the Default Container inside the UnityFallbackProviderStrategy class
public const string FALLBACK_PROVIDER_NAME = "UnityFallbackProvider";
#endregion
#region Vars
// The default Service Provider so I can Register it to the IUnityContainer
private IServiceProvider _defaultServiceProvider;
#endregion
#region Constructors
/// <summary>
/// Creates a new instance of the UnityFallbackProviderExtension class
/// </summary>
/// <param name="defaultServiceProvider">The default Provider used to fall back to</param>
public UnityFallbackProviderExtension(IServiceProvider defaultServiceProvider)
{
_defaultServiceProvider = defaultServiceProvider;
}
#endregion
#region Overrides of UnityContainerExtension
/// <summary>
/// Initializes the container with this extension's functionality.
/// </summary>
/// <remarks>
/// When overridden in a derived class, this method will modify the given
/// <see cref="T:Microsoft.Practices.Unity.ExtensionContext" /> by adding strategies, policies, etc. to
/// install it's functions into the container.</remarks>
protected override void Initialize()
{
// Register the default IServiceProvider with a name.
// Now the UnityFallbackProviderStrategy can Resolve the default Provider if needed
Context.Container.RegisterInstance(FALLBACK_PROVIDER_NAME, _defaultServiceProvider);
// Create the UnityFallbackProviderStrategy with our UnityContainer
var strategy = new UnityFallbackProviderStrategy(Context.Container);
// Adding the UnityFallbackProviderStrategy to be executed with the PreCreation LifeCycleHook
// PreCreation because if it isnt registerd with the IUnityContainer there will be an Exception
// Now if the IUnityContainer "magically" gets a Instance of a Type it will accept it and move on
Context.Strategies.Add(strategy, UnityBuildStage.PreCreation);
}
#endregion
}
UnityFallbackProvider策略:
public class UnityFallbackProviderStrategy : BuilderStrategy
{
private IUnityContainer _container;
public UnityFallbackProviderStrategy(IUnityContainer container)
{
_container = container;
}
#region Overrides of BuilderStrategy
/// <summary>
/// Called during the chain of responsibility for a build operation. The
/// PreBuildUp method is called when the chain is being executed in the
/// forward direction.
/// </summary>
/// <param name="context">Context of the build operation.</param>
public override void PreBuildUp(IBuilderContext context)
{
NamedTypeBuildKey key = context.OriginalBuildKey;
// Checking if the Type we are resolving is registered with the Container
if (!_container.IsRegistered(key.Type))
{
// If not we first get our default IServiceProvider and then try to resolve the type with it
// Then we save the Type in the Existing Property of IBuilderContext to tell Unity
// that it doesnt need to resolve the Type
context.Existing = _container.Resolve<IServiceProvider>(UnityFallbackProviderExtension.FALLBACK_PROVIDER_NAME).GetService(key.Type);
}
// Otherwise we do the default stuff
base.PreBuildUp(context);
}
#endregion
}
现在，如果我的 UnityContainer 没有注册某些东西，它只需向默认提供者询问即可。
我从几篇不同的文章中了解到了所有这些
这种方法的好处是我现在还可以“混合”依赖项。如果我需要任何服务和 ASP 的 IOptions 接口，我的 UnityContainer 将解析所有这些依赖项并将它们注入我的控制器！
唯一要记住的是，如果我使用任何自己的依赖项，我必须向 Unity 注册我的控制器类，因为默认的 IServiceProvider 无法再解析我的控制器依赖项。
最后：连线
现在，在我的项目中，我使用不同的服务（ASP 选项、带选项的 MVC）。为了使这一切正常工作，我的ConfigureServices方法现在看起来像这样：
public IServiceProvider ConfigureServices(IServiceCollection services)
{
// Add all the ASP services here
// #region ASP
services.AddOptions();
services.Configure<WcfOptions>(Configuration.GetSection("wcfOptions"));
var globalAuthFilter = new AuthorizationPolicyBuilder()
.RequireAuthenticatedUser()
.Build();
services.AddMvc(options => { options.Filters.Add(new AuthorizeFilter(globalAuthFilter)); })
.AddJsonOptions
(
options => options.SerializerSettings.ContractResolver = new DefaultContractResolver()
);
// #endregion ASP
// Creating the UnityServiceProvider
var unityServiceProvider = new UnityServiceProvider();
IUnityContainer container = unityServiceProvider.UnityContainer;
// Adding the Controller Activator
// Caution!!! Do this before you Build the ServiceProvider !!!
services.AddSingleton<IControllerActivator>(new UnityControllerActivator(container));
//Now build the Service Provider
var defaultProvider = services.BuildServiceProvider();
// Configure UnityContainer
// #region Unity
//Add the Fallback extension with the default provider
container.AddExtension(new UnityFallbackProviderExtension(defaultProvider));
// Register custom Types here
container.RegisterType<ITest, Test>();
container.RegisterType<HomeController>();
container.RegisterType<AuthController>();
// #endregion Unity
return unityServiceProvider;
}
因为我在过去的一周里学到了关于 DI 的大部分知识，所以我希望我没有打破任何大的原则/模式，如果是的话请告诉我！