帮我决定是否使用ASP.NET默认会员/角色提供商或编写自定义提供商

Question

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

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

默认提供程序

优点

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

缺点

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

自定义提供

优点

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

缺点

• 必须提供实现大多数/都要亲力亲为。
• 要使用任何控件，我将不得不在提供者中提供他们需要的实现。

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

谢谢。

Answer 1

我最近不得不作出相同的选择，并决定去创建一个自定义提供商。

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

此外，史蒂芬·桑德森说，这在Pro ASP.NET MVC 2框架：

...的SqlProfileProvider使用一个特别恶心的数据库模式，其中文件条目存储为冒号分隔的名称/值对，所以基本上不可能查询。总之，值得关注的是，由于关注的明确分离，跨项目的重用以及与其他ASP.NET的集成，因此值得关注，但是您只需要使用内置的SQL存储提供程序或一次性项目。

我没有通过创建自定义商尚未全过程走了（我做的时候我与Azure Table中存储播放部分实现），但我打算使用这些提供了在多个项目未来，所以我觉得这个努力将是非常值得的。

Answer 2

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

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

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

Answer 3

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

Answer 4

就我个人而言，我使用SqlMembershipProvider作为独立实体，而其余数据库在Oracle中。我从来没有看过数据库，所以名字和GUID不会打扰我（在视线之外，不在意）。它只是开箱即用，非常棒！

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

角色提供程序非常有限，如果您想要任何类型的层次结构或动态角色，则会进行烘烤。但它是一个与会员完全隔离的独立系统，您不必使用它。

控件并不差。他们中的很多人都支持模板，以便您可以将自己的控件添加到模板中，并且可以将大量事件挂接到模板中。不要害怕推出自己的控件，但首先给予默认控件一个机会。 Membership API的易用性确实有助于创建这些控件。