使用 Castle 的自定义成员资格提供程序中的属性注入
本文关键字：程序 属性 注入 Castle 自定义 成员 使用 | 更新日期: 2023-09-27 18:31:27
到目前为止，在阅读有关注入自定义成员资格提供程序的可能性时，我发现了两种可能的方法：
一是以下几点：http://bugsquash.blogspot.com/2010/11/windsor-managed-membershipproviders.html
在这里，作者基本上建议注册您的自定义提供程序，然后有一个相当可疑的温莎适配器作为成员资格（我不太喜欢它使用从HttpApplication获得的容器来实例您的提供程序的方式，它最终与温莎适配器一起包装）。
这是另一个类似的选项：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只是一些机制，可以被视为组合根的一部分，而不是应用程序的一部分。在合成根中调用容器不是问题。