2

到目前为止，在阅读有关向自定义会员提供程序注入的可能性时，我发现了两种可能的方法：

一个如下：http ://bugsquash.blogspot.com/2010/11/windsor-managed-membershipproviders.html

在这里，作者基本上建议注册您的自定义提供程序，然后为成员资格设置一个相当有问题的 Windsor 适配器（我真的不喜欢它使用它从中获取的容器来实例化您的提供程序的方式HttpApplication，它最终与 Windsor 适配器一起包装）。

这是另一个类似的选项：http ://code.google.com/p/webdotnet/source/browse/trunk/Steeg.Framework/Web/Security/MemberShipProvider.cs?r=2

您只需在其中覆盖Initialize()并手动实例化依赖项。至少在第一个中，您不需要手动实例化依赖项（除了提供者本身）。

然后有一些建议使用某种服务定位器（MVC 或其他）

然后我遇到了 ninjectMembership.Provider使用类似_kernel.Inject(Membership.Provider). 这更接近我想要的，保留了最初吸引我使用 DI 的组合根概念。

如何使用城堡获得类似的结果？

更新：显然这与生命周期管理有关。 使用 Ninject 将存储库注入自定义成员提供程序

那我应该选择＃1吗？至少我自己实例化了提供者。所以生命周期管理不应该是一个问题。

4

1 回答 1

2

我不会使用隐式属性注入，因为如果类型未（正确）注册，容器将跳过该属性，而不是快速失败（更多信息here）。相反，我将使用服务定位器，但编写一个不包含任何逻辑的包装成员提供程序，而只是从服务定位器请求一个成员提供程序并调用该实现。Jonas Gauffin为 MVC写了一个这样的东西（使用DependencyResolver服务定位器），这非常好（也可以在 NuGet 上使用），但自己很容易做到。

虽然使用服务定位器被认为是一种反模式，但请记住，会员模型必须通过 web.config 进行配置，并且这部分系统不使用它DependencyResolver.Current本身。编写这样的 aDependencyResolverMembershipProvider也只是一些技巧，可以被认为是组合根的一部分，而不是应用程序的一部分。在组合根目录中调用容器不是问题。

于 2012-04-17T07:23:00.573 回答