具有存储库模式的 .NET 成员资格
我的团队正在设计一个域模型，该模型将在统一的存储库抽象后面隐藏各种不同的数据源。这种方法的主要驱动因素之一是这些数据源在不久的将来很可能会发生重大变化，并且我们不希望在发生这种情况时重写业务逻辑。一个数据源是我们的会员数据库，该数据库最初是使用默认的 ASP.Net 会员提供程序实现的。成员资格提供程序与 System.Web.Security 命名空间绑定，但我们有一个设计指南，要求我们的域模型层不依赖于 System.Web（或任何其他实现/环境依赖项），因为它将在不同的环境中使用 -我们也不希望我们的网站直接与数据库通信。
我正在考虑什么是协调 MembershipProvider 方法与我们抽象的 n 层架构的好方法。我最初的感觉是，我们可以创建一个与域模型交互的“DomainMembershipProvider”，然后在模型中实现处理存储库并处理验证/业务逻辑的对象。然后，存储库将使用我们的（尚未确定的）ORM/数据访问工具来实现数据访问。
这种方法是否有任何明显的漏洞 - 我没有与 MembershipProvider 类密切合作，因此很可能会遗漏一些东西。或者，您认为是否有一种方法可以更好地满足我上面描述的要求？
预先感谢您的想法和建议。
问候， 扎克
My team is in the process of designing a domain model which will hide various different data sources behind a unified repository abstraction. One of the main drivers for this approach is the very high probability that these data sources will undergo significant change in the near future and we don't want to be re-writing business logic when this happens. One data source will be our membership database which was originally implemented using the default ASP.Net Membership Provider. The membership provider is tied to the System.Web.Security namespace but we have a design guideline requiring that our domain model layer is not dependent upon System.Web (or any other implementation/environment dependency) as it will be consumed in different environments - nor do we want our websites directly communicating with databases.
I am considering what would be a good approach to reconciling the MembershipProvider approach with our abstracted n-tier architecture. My initial feeling is that we could create a "DomainMembershipProvider" which interacts with the domain model and then implement objects in the model which deal with the repository and handle validation/business logic. The repository would then implement data access using our (as-yet undecided) ORM/data access tool.
Are there are any glaring holes in this approach - I haven't worked closely with the MembershipProvider class so may well be missing something. Alternatively, is there an approach that you think will better serve the requirements I described above?
Thanks in advance for your thoughts and advice.
Regards,
Zac
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
自问题提出以来已经过去 6 个月了，似乎没有人能够提供答案，所以我想我应该解释一下我们最终选择的解决方案。
基本上，我们决定不使用 MembershipProvider 的任何实现 - 相反，我们使用位于存储库之上的我们自己的自定义会员服务。对我们来说，维护现有的 aspnet_Membership 数据库非常重要，因此我们的存储库基本上复制了内置的 SQLMembershipProvider 功能（至少是我们需要的方面） - 最初通过 Linq-to-SQL，但现在我们正在过渡到 NHibernate 。计划在一年左右的时间内更换会员数据库，届时我们所有的网站都升级为使用新模型。
可以使用自定义成员资格提供程序，但最终发现使用自定义实现更简单、更一致且更易于维护。我们仍在使用内置的表单身份验证功能来验证用户是否已登录，并重定向尝试在未经身份验证的情况下访问我们网站的安全区域的用户 - 但我们已经覆盖了与配置文件提供程序相关的功能。
最终，我们对此的感受是，虽然成员资格提供程序是 ASP.Net 中功能强大且易于使用的工具，但如果它不适合您的应用程序中使用的更广泛的方法，则值得考虑其他方法。
It's been 6 months since the question was asked and no one seems to have been able to provide an answer so I thought I'd explain the solution we eventually chose.
Basically, we have decided not to use any implementation of the MembershipProvider - instead we use our own custom Membership Service sitting atop a repository. It was important for us to maintain the existing aspnet_Membership database so our repository has basically duplicated the built-in SQLMembershipProvider functionality (at least, the aspects we need of it) - initially via Linq-to-SQL but now we're transitioning to NHibernate. The plan is to replace the membership database in a year or so when all of our websites are upgraded to use the new model.
It was possible to use a custom membership provider but in the end it became apparent that it was simpler, more consistent, and more maintainable to use a custom implementation. We are still using the built-in forms authentication functionality for verifying that a user is logged in and for redirecting users who try to access secure areas of our site without first being authenticated - but we have overridden the functionality that is tied to the profile provider.
Ultimately, our feelings on this are that while the membership provider is a powerful and easy-to-use tool within ASP.Net, if it doesn't fit with the wider approach used in your application, it is worth considering an alternative approach.
有趣，感谢您发布最终解决方案。我处于类似的情况，但编写了一个自定义会员提供程序。我不知道将提供程序放在哪里，因为它需要访问数据库以及 System.Web 命名空间。看起来它是一个违反整个关注点分离设计的类。
Interesting, thanks for posting your final solution. I am in a similar situation, but writing a custom Membershipprovider. I don't know where to put the provider because it needs access to the DB as well as System.Web namespace. It seems like it's the one class that violates this whole separation of concerns design.