2

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

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

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

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

问候，扎克

4

2 回答 2

2

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

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

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

最后，我们对此的感觉是，虽然成员资格提供程序是 ASP.Net 中功能强大且易于使用的工具，但如果它不适合您的应用程序中使用的更广泛的方法，则值得考虑另一种方法。

于 2010-04-20T23:01:07.203 回答
0

有趣，感谢您发布最终解决方案。我处于类似情况，但编写了一个自定义 Membershipprovider。我不知道将提供程序放在哪里，因为它需要访问数据库以及 System.Web 命名空间。似乎它是违反整个关注点分离设计的一类。

于 2011-01-20T18:04:08.197 回答