Question

我目前正在重构我们的后端，在此过程中，我已经删除了对ServiceLocator的依赖。但！现在这让我头疼的是在从Web.config中提取需要注入的类型时如何进行依赖注入。目前的具体案例是：

<system.identityModel>
    <identityConfiguration>
      <claimsAuthenticationManager type="MyNamespace.MyClaimsAuthenticationManager, MyAssembly, Version=1.0.0.0, Culture=neutral" />
      <claimsAuthorizationManager type="MyNamespace.MyClaimsAuthorizationManager, MyAssembly, Version=1.0.0.0, Culture=neutral" />
      <securityTokenHandlers>
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler,System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler,System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <securityTokenHandlerConfiguration maximumClockSkew="5"></securityTokenHandlerConfiguration>
      </securityTokenHandlers>
    </identityConfiguration>
</system.identityModel>

此处MyClaimsAuthenticationManager和MyClaimsAuthorizationManager类型是需要注入依赖项的类型。

该项目在.NET 4.5下运行，目前正在使用Ninject作为依赖项注入部分。

Answer 1

.NET中的can't do DI with the Provider mechanisms，主要是因为它依赖于Constrained Construction反模式。

您最好的选择是找到一个不依赖于.NET提供程序机制的更好的设计。

如果这是不可能的，那么您的下一个最佳选择是将提供商（在这种情况下为MyClaimsAuthenticationManager和MyClaimsAuthorizationManager）视为Humble Objects，每个提供商都包含Composition Root组成的Adapters完成工作的实际对象图。换句话说，您可以将这些提供者视为my book而不是您需要启动的任何对象图，以便进行实际工作。

在{{3}}中，我将在7.5节中更详细地介绍这种方法。

在type =“”属性上使用依赖注入

1 个答案: