到目前为止，在阅读有关注入自定义会员提供商的可能性时，我发现了两种可能的方法：
以下是：http://bugsquash.blogspot.com/2010/11/windsor-managed-membershipproviders.html
这里作者基本上建议注册你的自定义提供者，然后有一个相当可疑的windsor适配器用于成员资格（我真的不喜欢它使用从HttpApplication获得的容器实现你的提供者的方式，它最终包含了windsor适配器。）
您只需覆盖Initialize()并在那里手动实例化依赖项。至少在第一个中，您不需要手动实例化依赖项（除了提供程序本身）。
还有一些建议使用某种服务定位器（MVC或其他）
然后我遇到ninject在Membership.Provider上向属性注入依赖项，而不是像_kernel.Inject(Membership.Provider)那样容易。这更接近我想要的，保持构图根本概念，这使我首先使用DI。
如何使用城堡获得类似的结果？
更新：显然这有生命周期管理的问题。 Inject repository to custom membership provider with Ninject
我应该选择＃1选项吗？至少我自己实例提供者。因此，生命周期管理不应成为问题。
答案 0 :(得分：2)
我不会使用隐式属性注入，因为如果类型没有（正确）注册，容器将跳过属性，而不是快速失败（更多信息here）。相反，我会使用服务定位器，但编写一个不包含任何逻辑的包装器成员资格提供程序，只是从服务定位器请求成员资格提供程序并调用该实现。 Jonas Gauffin写了such a thing for MVC（使用DependencyResolver服务定位器），这非常好（也是available on NuGet），但很容易做到。
虽然服务定位器的使用被认为是反模式，但请记住，必须通过web.config配置成员模型，并且系统的这一部分不使用DependencyResolver.Current本身。编写这样的DependencyResolverMembershipProvider只是一些机制，可以被认为是组合根的一部分，而不是应用程序的一部分。在组合根目录中调用容器不是问题。