asp.net-mvc-3 - ASP.NET MVC3 : Do I need to use a MembershipProvider?

Question

我正在使用 MVC3 构建一个 Multi-Tenancy 站点。在这个项目之前，我从来没有接触过 .NET 堆栈或一般的 Web 开发，所以你可以想象我的领域知识有些缺乏。

我仍在使用默认的 AccountController 架构，但我很快确定我不想使用 aspnetdb.mdf 进行身份验证，因为它的设计与我的要求完全不同。我确实想要基于角色的身份验证，所以我最终将自定义用户和角色类编写为代码优先实体类并使用 this tutorial设置自定义 MembershipProvider 和 RoleProvider。

目前一切正常，但是当我正在构建 Multi-Tenancy 功能时，它变得越来越困惑。基于 this example ，我正在使用 Controller 的自定义扩展来跟踪哪个租户正在使用此 session ，并且我的所有 Controller 都扩展了此类而不是基本 Controller 类。

所有租户都使用相同的数据库。每个实体都有一个租户属性，用于标识它属于谁。

所以，问题来了:
用户名不需要是全局唯一的。只有用户名和租户的组合必须是唯一的。因此，ValidateUser 需要知道用户名、密码和租户。由于我的自定义 MembershipProvider 不是 Controller ，它不知道哪个租户正在使用 session ，并且 ValidateUser 方法只接受用户名和密码，因此我无法将这些信息传递给它。

此外，除了 ValidateUser 之外，MembershipProvider 所做的几乎所有事情都已经在 UserRepository 类中实现，该教程告诉我要做。我比较喜欢 Repository 模式，它比坚持 MembershipProvider 的接口(interface)方便得多，但现在 UserRepository 和 MembershipProvider 之间存在巨大的利益冲突。

所以，我的问题:
我是否需要使用 MembershipProvider，甚至是 Membership？
似乎 MembershipProvider 所做的一切都会由我的存储库类更方便地执行。在这一点上，我所要做的就是编写一个不依赖于 Membership 的新 Authorize 属性，并且在没有任何 MembershipProvider 的情况下一切都应该工作，对吧？如果我不放弃 Membership，我将被迫完全破坏我的 MembershipProvider 实现，以至于它几乎不像原来的接口(interface)。

...无论是那个还是成员(member)资格都会做很多我不知道的事情，删除它是公然的愚蠢。这也是一种明显的可能性。

Answer 1

不，您不需要使用 Membership，但请考虑一下 Membership 究竟是什么。成员(member)资格不涉及您的用户名、地址或其他信息。成员(member)资格与系统的登录帐户密切相关。它仅处理有关创建、验证、更新或删除登录所需信息的详细信息。就是这样。

同样，角色系统只是为用户分配角色名称。

最终，Membership 和 Roles 只是 IPrincipal 接口(interface)的实现。而 FormsAuthentication 是 IIdentity 接口(interface)的实现。它们一起工作，以便您可以利用内置的 ASP.NET 授权和身份验证系统。

成员(member)制实际上确实有多个租户的概念。此功能是通过 aspnet_users 表的“ApplicationNane”字段完成的(也可在 Membership 类本身中设置)

从 Membership 类的文档中:

The ApplicationName is used to identify users specific to an application. That is, the same user name can exist in the database for multiple ASP.NET applications that specify a different ApplicationName. This enables multiple applications to use the same database to store user information without running into duplicate user name conflicts. Alternatively, multiple ASP.NET applications can use the same user database by specifying the same ApplicationName. The ApplicationName can be set programmatically or declaratively in the configuration for the Web application.

现在，这通常被设计为在 Web.Config 中设置，并在应用程序的生命周期内保持不变，但我看不出为什么你不能使用它来指定你想要的租户。

这里唯一的问题是 Membership.ApplicationName 是静态的，这意味着它被应用程序池中运行的所有线程共享。但是，如果您使用某种锁定来访问它，那么这应该不是一个大问题(尽管它可能会在某种程度上影响可伸缩性)。

这基本上允许您使用标准的、开箱即用的成员资格提供程序，而无需进行任何更改。您只需确保保护访问调用。