c# - 使用 CaSTLe 在自定义成员提供程序中注入(inject)属性

Question

到目前为止，在阅读有关注入(inject)自定义成员资格提供程序的可能性时，我发现了两种可能的方法:

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

在这里，作者基本上建议注册您的自定义提供程序，然后有一个相当可疑的温莎适配器作为成员资格(我真的不喜欢它使用从 HttpApplication 获取的容器实例化您的提供程序的方式，它最终用 windsor 适配器包装)。

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

您刚刚覆盖 Initialize() 的地方并在那里手动实例化依赖项。至少在第一个中，您不需要手动实例化依赖项(提供者本身除外)。

还有一些建议使用某种服务定位器(MVC 或其他方式)

然后我遇到了 ninject 向 Membership.Provider 上的属性注入(inject)依赖项使用类似 _kernel.Inject(Membership.Provider) 的东西相当容易.这更接近我想要的，保留了最初吸引我使用 DI 的组合根概念。

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

更新:显然这与生命周期管理有关。 Inject repository to custom membership provider with Ninject

那么我应该选择选项 1 吗？至少我自己实例化了提供者。因此，生命周期管理应该不是问题。

Answer 1

我不会使用隐式属性注入(inject)，因为如果类型没有(正确)注册，容器将跳过该属性，而不是快速失败(更多信息 here )。相反，我会使用服务定位器，但编写一个不包含任何逻辑的包装器成员提供程序，而只是从服务定位器请求一个成员提供程序并调用该实现。 Jonas Gauffin写了such a thing for MVC (使用 DependencyResolver 服务定位器)，这非常好(也是 available on NuGet )，但是您自己做起来很容易。

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