C# 帮助我决定是使用ASP.NET默认成员资格/角色提供程序还是编写自定义提供程序

昨天我花了很大一部分时间阅读这个主题，但仍然觉得我不确定该走哪条路。当涉及到身份验证和授权时，我来自一个“滚你自己的”背景。我们从未使用表单身份验证，更不用说成员身份API了。查看我们的旧代码，我们将使用会话变量来捕获/控制用户是否登录等。对于我即将开始的这个新项目，我想让我们回到我们应该开始做的事情上，即使用框架提供的工具

我已经有了一个我将使用的数据库模式，但是它不是一成不变的；如有必要，我可以对其进行更改。在这个模式中已经有一个Users表，它使用一个整数作为主键。此表还包含其他信息，如姓名和姓氏。我也有基于UserId的外键到其他表，比如Phone和Address。下面我概述了我想到的一些优点/缺点

默认提供程序

专业人士

• 更少的代码
• 能够利用所有相关的服务器控件，如登录、更改密码

缺点

• 有些控件可能对我不太有用。例如，在CreateUserWizard中，我可能需要在用户创建期间捕获其他信息，例如关联表中的电话和地址信息。不确定这是否会使此控件对我无效
• 我必须在关联的表（电话、地址）中为UserId创建外键，UserId是默认提供程序中的GUID
• 如果我创建了这些外键约束，而没有使用级联删除；我还需要删除外键表中的关联行。可能需要利用TransactionScope对象之类的东西来确保所有这些都是原子操作

自定义提供程序

专业人士

• 能够利用现有的模式表
• 更容易将身份验证/授权提取到服务中

缺点

• 必须自己为大多数/所有事情提供实施
• 要使用任何控件，我必须在提供程序中提供它们所需的实现

可能还有其他事情我还没有考虑过，因为我以前从未使用过，这也让我有点不舒服

---

谢谢。

就我个人而言，我同意框架提供的内容。在这种情况下，没有理由使用您自己的身份验证

在过去，你可能想自己做事情，但现在没有理由这样做

---

我认为，如果你试图自己写这篇文章，你会重新创造轮子，需要花费太多的时间和资源才能把它做好。尤其是在处理安全问题时。

如果您正在构建一个新的应用程序，我会毫不犹豫地使用asp.net默认提供程序。您可以随时决定不使用默认控件，并通过编程创建自己的控件。您还可以通过使用任何开源预创建的用户管理工具节省大量时间。同时，您可以随时扩展默认表中包含的信息。

我最近不得不做出同样的选择，并决定继续创建自定义提供程序

我这样做的最大原因是默认的db模式。所有默认的db对象都是在dbo模式中创建的，并以“aspnet”或“vw_aspnet”等为前缀。对我来说，这是一个真正的关闭。如果尚未看到它们，请运行aspnet_regsql.exe创建它们

此外，Steven Sanderson在Pro ASP.NET MVC 2框架中说：

…SqlProfileProvider使用了一种特别令人厌恶的数据库模式，其中配置文件条目存储为冒号分隔的名称/值对，因此基本上不可能进行查询

总的来说，遵循API是值得的，因为它可以清晰地分离关注点，跨项目重用，并与ASP.NET的其余部分集成，但您只希望在小型或一次性项目中使用内置SQL存储提供程序

---

我还没有完成创建自定义提供程序的整个过程（我在使用Azure Table storage时做了部分实现），但我计划在未来的多个项目中使用这些提供程序，因此我觉得这是值得的。

就我个人而言，我使用SqlMembershipProvider作为独立实体，而数据库的其余部分在Oracle中。我从来不看数据库，所以名称和guid不会困扰我（看不见，想不起来）。它只是开箱即用，太棒了

在我的场景中，我在Oracle数据库中有一个用户表，在创建/删除成员资格用户（无GUID）时插入/删除该表。我认为成员数据库是“主”记录，Oracle表基本上用于支持表的引用完整性。这实际上不是在正式事务中完成的，但我使用try/catch来保持它们足够好的同步

角色提供者是非常有限的，如果你想要任何层次或动态角色，你会被敬酒的。但是它是一个完全独立于成员的系统，你不必使用它

---

控制还不错。它们中的很多都支持模板，因此您可以向模板中添加自己的控件，并且有大量事件可以挂接到模板中。不要害怕滚动您自己的控件，但是首先给默认控件一个机会。成员API的易用性确实有助于创建这些控件。

我也在学习这种方法，模式对我来说似乎非常有限。我真的不想使用他们的guid作为外键。我必须在应用程序中编写自己的管理屏幕（管理员用户可以创建其他屏幕）