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

Question

昨天我花了大量时间阅读这个主题，但仍然觉得我不知道该走哪条路。在身份验证和授权方面，我来自“自己动手”的背景。我们从未使用过Forms身份验证，更不用说Membership API了。看看我们的旧代码，我们将使用会话变量来捕获/控制用户是否已登录等。通过这个新项目，我即将承诺，我想让我们回到正轨，我们应该开始做什么，哪个是使用框架提供的工具。

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

默认提供商

赞成

• 少量代码。
• 能够利用所有相关的服务器控件，例如Login，ChangePassword。

缺点

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

自定义提供商

赞成

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

缺点

• 必须自己为大部分/全部提供实施。
• 要使用任何控件，我必须在提供程序中提供所需的实现。

可能还有其他一些我还没有考虑过的事情，因为我之前从未使用过这些东西，这让我有点不舒服。

谢谢。

Answer 1

我最近不得不做出同样的选择，并决定创建自定义提供商。

我这样做的最大原因归结为默认的数据库架构。所有默认的db对象都是在dbo架构中创建的，并以'aspnet_'或'vw_aspnet'等为前缀。对我而言，这是一次真正的岔路。如果还没有看到它们，请运行aspnet_regsql.exe来创建它们。

此外，Steven Sanderson在Pro ASP.NET MVC 2 Framework中说明了这一点：

  

... SqlProfileProvider使用特别恶心的数据库模式，其中配置文件条目存储为冒号分隔的名称/值对，因此基本上无法查询。

     

总的来说，值得关注API，因为关注点明确分离，跨项目重用，以及与ASP.NET的其余部分集成，但您只想将内置的SQL存储提供程序用于小型或一次性项目。

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

Answer 2

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

Answer 3

就个人而言，我使用SqlMembershipProvider作为独立实体，而我的数据库的其余部分在Oracle中。我从不看数据库，因此名字和GUID不会打扰我（看不见，不在乎）。它开箱即用，非常棒！

在我的场景中，我在Oracle数据库中有一个用户表，我在创建/删除成员资格用户时没有插入/删除（没有GUID）。我认为成员资格数据库是“主”记录，而Oracle表基本上是支持表的参照完整性。在官方交易中并没有真正完成，但我使用try / catch来保持它们的同步性。

角色提供者真的是有限的，如果你想要任何类型的分层或动态角色，你就会被烘烤。但它是一个完全独立于会员资格的独立系统，您不必使用它。

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

Answer 4

就个人而言，我会选择框架提供的内容。在这种情况下，没有理由推出自己的身份验证。

在过去，你可能想要自己做事，但现在没有理由。

我想如果你试图自己写这个，你就会重新创造轮子，这需要花费太多的时间和资源才能做到正确。特别是在处理安全问题时。