具有存储库模式的.NET成员资格

Question

我的团队正在设计一个域模型，该模型将隐藏统一存储库抽象背后的各种不同数据源。这种方法的主要驱动因素之一是这些数据源在不久的将来会发生重大变化的可能性非常高，我们不希望在发生这种情况时重写业务逻辑。一个数据源将是我们的成员资格数据库，最初使用默认的ASP.Net成员资格提供程序实现。成员资格提供程序与System.Web.Security命名空间绑定，但我们有一个设计准则要求我们的域模型层不依赖于System.Web（或任何其他实现/环境依赖），因为它将在不同的环境中使用 - 我们也不希望我们的网站直接与数据库通信。

我正在考虑将MembershipProvider方法与抽象的n层架构进行协调的好方法。我最初的感觉是我们可以创建一个“DomainMembershipProvider”，它与域模型交互，然后在模型中实现处理存储库和处理验证/业务逻辑的对象。然后，存储库将使用我们（尚未确定的）ORM /数据访问工具实现数据访问。

这种方法是否有任何明显的漏洞 - 我没有与MembershipProvider类密切合作，所以可能会遗漏一些东西。或者，您认为是否有更好地满足上述要求的方法？

提前感谢您的想法和建议。

此致 扎克

Answer 1

问题问题已经过去了6个月，似乎没有人能够提供答案，所以我想我会解释我们最终选择的解决方案。

基本上，我们决定不使用MembershipProvider的任何实现 - 而是使用我们自己的自定义成员服务，位于存储库的顶部。维护现有的aspnet_Membership数据库对我们来说很重要，因此我们的存储库基本上复制了内置的SQLMembershipProvider功能（至少，我们需要的方面） - 最初通过Linq-to-SQL但现在我们正在转换到NHibernate 。计划是在我们所有网站升级为使用新模型的一年左右时更换会员数据库。

可以使用自定义成员资格提供程序，但最终显然使用自定义实现更简单，更一致，更易于维护。我们仍在使用内置的表单身份验证功能来验证用户是否已登录，以及重定向尝试访问我们站点的安全区域的用户，而无需先进行身份验证 - 但我们已覆盖与配置文件提供程序关联的功能

最终，我们对此的感受是，尽管会员提供商是ASP.Net中功能强大且易于使用的工具，但如果它不适合您的应用程序中使用的更广泛的方法，则值得考虑替代方法。

Answer 2

有意思，感谢您发布最终解决方案。我处于类似的情况，但写了一个自定义的Membershipprovider。我不知道将提供程序放在何处，因为它需要访问DB以及System.Web命名空间。看起来这是违反整个关注设计分离的一类。