asp.net - 使用 ASP.NET SQL Membership Provider，我如何存储我自己的每用户数据？

Question

我正在使用 ASP.NET SQL 成员资格提供程序。所以，有一个 aspnet_Users包含我的每个用户的详细信息的表。 (实际上，aspnet_Membership 表似乎包含了大部分实际数据)。

我现在想在我的数据库中存储一些每个用户的信息，所以我想我只需创建一个带有 UserId 的新表。 (GUID) 列和与 aspnet_Users 的 FK 关系.但是，我随后发现我无法轻松访问 UserId因为它不是通过成员(member) API 公开的。 (我知道我可以通过 ProviderUserKey 访问它，但似乎 API 正在抽象出内部 UserID 以支持 UserName ，我不想走得太远)。

所以，我想我应该放一个 LoweredUserName列，并创建到 aspnet_Users 的 FK 关系使用那个。呸。又错了，因为虽然在 aspnet_Users 中有一个唯一索引包括 LoweredUserName ，它还包括 ApplicationId - 所以为了建立我的 FK 关系，我需要有一个 ApplicationId我表中的列也是。

起初我想:好吧，我只处理一个应用程序，所以我只添加这样一个列并给它一个默认值。然后我意识到ApplicationId是一个 GUID，所以这样做会很痛苦。不难，但在我推出我的数据库之前，我无法预测 GUID 会是什么。

我觉得我错过了什么，或者以错误的方式处理事情。我应该做些什么？

Answer 1

我认为您正在寻找 ProfileProvider，它可以让您将您希望的任意信息与用户相关联。

ASP.NET Profile Properties Overview

附加 如果内置的 ProfileProvider 不能满足您的需求，那么您可以考虑通过编写一个派生自 System.Web.Profile.ProfileProvider 的类来实现您自己的 ProfileProvider。 .这将使您能够编写一些内容来避免您在评论中提到的序列化问题。

Implementing a Profile Provider

附加 关于 SqlMembershipProvider 的注意事项。您确实是正确的，即使架构以 UserId 为键，Membership 类也确实以用户名为键。坦率地说，这是我对 SqlMembershipProvider 类最不满意的地方之一。这实际上会在多应用程序环境中产生问题，在该环境中您需要单个用户存储但独立的应用程序角色列表。

我的建议是键入 UserId，因为正如您所提到的，它是 aspnet_Users 表的主键，用于所有外键关系，并且它是单个值。如果您键入 LowerUsername(和 ApplicationId)，并且用户名发生更改，则您需要启用级联更新，以便更改影响您的自定义表。