使用Castle在自定义成员资格提供程序中注
到目前为止，在阅读有关注入自定义会员提供商的可能性时，我发现了两种可能的方法：
一个是以下内容： 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或其他）
然后我遇到了ninject注入依赖于Membership.Provider上的属性，而不是像_kernel.Inject(Membership.Provider)那样容易。 这更接近我想要的东西，保持构图根本概念，这使我首先使用DI。
如何使用城堡获得类似的结果？
更新：显然这有生命周期管理的问题。 使用Ninject将存储库注入自定义成员资格提供程序
我应该选择＃1选项吗？ 至少我自己实例提供者。 因此，生命周期管理不应成为问题。
我不会使用隐式属性注入，因为如果类型没有（正确）注册，容器将跳过属性，而不是快速失败（ 这里有更多信息）。 相反，我会使用服务定位器，但编写一个不包含任何逻辑的包装器成员资格提供程序，只需从服务定位器请求成员资格提供程序并调用该实现。 Jonas Gauffin 为MVC编写了这样的东西 （使用DependencyResolver服务定位器），这非常好（也可以在NuGet上使用 ），但是很容易自己做。
虽然服务定位器的使用被认为是反模式，但请记住，必须通过web.config配置成员模型，并且系统的这一部分不使用DependencyResolver.Current本身。 编写这样的DependencyResolverMembershipProvider也只是一些机制，可以被认为是组合根的一部分，而不是应用程序的一部分。 在组合根目录中调用容器不是问题。