8

在 asp.net 4 中设计一个新应用程序 我必须决定如何使用 MS SQL Membership API 以及我自己在 MS SQL 数据库中的数据。首先,我需要以比 Profile 提供者支持的更灵活的方式存储和访问用户配置文件数据。其次,我想链接其他用户相关信息(例如订单)。

无论您将 aspnetdb 表存储在何处(在单独的数据库中或与您的数据在同一个数据库中),问题都在于如何保持数据同步。

经过研究,我看到以下相关选项:
1. 来自 asp_Users 的外键 UserId(教程中建议)。
2. 无外键使用交易(这里推荐)。
3.无外键——使用自定义的AccountController(不管是什么,这里建议)。
4. 将 Membership UserId (uid) 与自定义 UserId (int) 链接的附加表。
5. ...

一方面,我喜欢第一个解决方案,因为它非常简单,并且在官方的 asp.net 教程中有所建议。

另一方面,反对者相当合理地指出,使用外键打破了提供者的一般概念,提供者应该有助于分离关注点并可以互换。但不幸的是,他们并没有过多地讨论实施细节,因此很难根据相关性和实施的难易程度来评估这些建议。

那么解决这个问题的最佳选择是什么?此外,实施情况如何?仅使用额外的 ADO.NET 或 LINQ 等代码就足够了吗,还是值得实现自定义成员资格和/或配置文件提供程序?

先感谢您。

4

2 回答 2

7

第一种是最简单的方法。在相关表中添加用户的 GUID 作为外键 (fe Ordered_by)。我看不出它在哪里打破了分离的关注点。如果您想将订单记录保留在数据库中,您还必须保留已订购的用户,这非常有意义。

我在当前的应用程序中成功使用了选项 4。我创建了一个主键和 fiUser(的 GUID aspnet_UserID)作为外键的表。这是模型:idUser intaspnet_Users

数据模型

(注意:是通过aspnet_regsql.exeUser创建的标准表,是我的自定义表,它将每个 Guid 映射到我的 int-ID)aspnet_Usersaspnet_UserId

现在我只idUser在所有相关表中存储我的 as FK(比如在您的订单表中)。这具有更少存储空间和更易读的用户 ID(我永远记不起 GUID)的优势。也许它与这个“包装表”更加分离,但这不是我的主要意图。

如果要控制行为,可以更改外键的删除规则。Cascade如果您想删除您要删除的用户订购的所有订单,请将其设置为,如果no Action您想保留此订单,请将其设置为。

我不能为个人资料问题提出任何替代方案,因为您没有提到“需要以比个人资料提供者支持的更灵活的方式存储和访问用户个人资料数据”的意思。

于 2011-06-30T09:19:14.443 回答
1

您应该考虑编写自己的自定义成员资格提供程序,该提供程序根据您的需要使用表/数据(而不是使用 ASP.NET 提供的架构)。

请参阅此 MSDN 示例(架构代码)以编写自定义提供程序 - 此示例使用 OLEDB 访问数据库。另一个示例在这里- 它使用活动目录作为存储。

于 2011-06-30T09:18:36.640 回答