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

Question

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

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

默认提供商

优点

• 更少的代码.
• 能够利用所有相关的服务器控件,例如Login,ChangePassword.

缺点

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

定制提供商

优点

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

缺点

• 必须自己为大多数/一切提供实施.
• 要使用任何控件,我必须在提供程序中提供所需的实现.

可能还有其他我还没有考虑过的事情,因为我之前从未使用过这个,这让我有点不舒服.

谢谢.

Answer 1

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

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

另外，Steven Sanderson 在 Pro ASP.NET MVC 2 Framework 中这样说：

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

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

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