我昨天花了很大一部分时间阅读这个主题，但仍然觉得我不确定该走哪条路。在身份验证和授权方面，我有“自己动手”的背景。我们从未使用过 Forms 身份验证，更不用说 Membership API。查看我们的旧代码，我们将使用 session 变量来捕获/控制用户是否登录等。对于我即将进行的这个新项目，我想让我们回到正轨，开始我们应该做的事情，这是使用框架提供的工具。
我已经有了一个要使用的数据库模式，但它不是一成不变的；如有必要，我可以对其进行更改。在这个模式中已经有一个 Users 表，使用一个整数作为主键。该表还包含其他信息，例如名字和姓氏。我也有基于 UserId 的外键到其他表，如电话和地址。下面我概述了我想到的一些优点/缺点。
默认提供商
优点
- 更少的代码。
- 能够使用所有相关的服务器控件，例如登录、更改密码。
缺点
- 一些开箱即用的控件可能对我没有用。例如 CreateUserWizard，我可能需要在用户创建期间捕获其他信息，例如关联表的电话和地址信息。不确定这是否会使此控件对我无用。
- 我必须在我的关联表(电话、地址)中为默认提供程序中的 GUID UserId 创建外键。
- 如果我确实创建了这些外键约束并且没有使用级联删除；我还需要删除外键表中的关联行。可能必须利用 TransactionScope 对象之类的东西来确保所有这些都是原子操作。
自定义供应商
优点
- 能够利用现有架构表。
- 更容易将身份验证/授权提取到服务中。
缺点
- 必须自己为大部分/所有事情提供实现。
- 要使用任何控件，我必须在提供程序中提供它们所需的实现。
可能还有其他事情我还没有考虑，因为我以前从未使用过它，这也让我有点不舒服。
谢谢。
最佳答案
我最近不得不做出相同的选择，并决定继续创建自定义提供程序。
我这样做的最大原因归结为默认的数据库模式。所有默认的数据库对象都是在 dbo 架构中创建的，并以“aspnet_”或“vw_aspnet”等为前缀。对我来说，这是一个真正的关闭。如果您还没有看到它们，请运行 aspnet_regsql.exe 来创建它们。
此外，Steven Sanderson 在 Pro ASP.NET MVC 2 Framework 中说:
...SqlProfileProvider uses an especially disgusting database schema, in which profile entries are stored as colon-separated name/value pairs, so it's basically impossible to query.
Overall, it's worth following the API because of the clear separation of concerns, reuse across projects, and integration with the rest of ASP.NET, but you'll only want to use the built-in SQL storage providers for small or throwaway projects.
我还没有完成创建自定义提供程序的整个过程(我在使用 Azure 表存储时确实做了部分实现)，但我计划在未来的多个项目中使用这些提供程序，所以我觉得这些努力是值得的。
关于c# - 帮助我决定是使用 ASP.NET 默认成员资格/角色提供程序还是编写自定义提供程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3873641/