如何将Membership API与自己的应用程序相关数据结合起来？
在 asp.net 4 中设计一个新应用程序时，我必须决定如何使用 MS SQL 成员资格 API 以及 MS SQL 数据库中我自己的数据。首先，我需要以比配置文件提供程序支持的更灵活的方式存储和访问用户配置文件数据。其次，我想链接其他用户相关信息（例如订单）。
无论您将 aspnetdb 表存储在何处（在单独的数据库中或与您的数据在同一数据库中），问题仍然是如何保持数据同步。
经过研究，我看到以下相关选项：
1.来自asp_Users的外键UserId（在this 教程）。
2.无外键-使用事务（建议此处)。
3.没有外键 - 使用自定义的AccountController（无论它是什么，建议此处）。
4. 将会员用户 ID (uid) 与自定义用户 ID (int) 链接起来的附加表。
5. ...
一方面，我喜欢第一个解决方案，因为它非常简单，并且在官方 asp.net 教程中得到了建议。
另一方面，反对者相当合理地指出，使用外键打破了提供者的总体理念，提供者应该有助于分离关注点并可互换。但不幸的是，他们并没有深入探讨实施细节，因此要评估这些建议的相关性和实施难易程度并不容易。
那么解决这个问题的最佳选择是什么？此外，实施会是什么样子？仅使用额外的 ADO.NET 或 LINQ 等代码就足够了，还是值得实现自定义成员资格和/或配置文件提供程序？
先感谢您。
Designing a new application in asp.net 4 I have to make a decision how to use a MS SQL Membership API along with my own data in the MS SQL data base. Firstly I need to store and access user profile data in more flexible manner then the Profile provider supports. Secondly I would like to link other user related information (e.g. Orders).
No matter where you store your aspnetdb tables (in the separate data base or in the same data base with your data), the problem stays how to keep your data synchronized.
After a research I see the following relevant options:
1. Foreign key UserId from asp_Users (suggested in this tutorial).
2. No foreign key - use transactions (suggested here).
3. No foreign key - use customized AccountController (whatever it is, suggested here).
4. Additional table which links Membership UserId (uid) with custom UserId (int).
5. ...
On the one hand I like the first solution as it is quite straightforward and is suggested in an official asp.net tutorial.
On the other hand opponents note quite reasonably that using foreign keys breaks the general idea of providers which are supposed to help separating concerns and to be interchangeable. But unfortunately they do not go much into implementation details so it is not really easy to estimate those suggestions in terms of relevance and ease of implementation.
So what is the best option to approach this? Furthermore how would the implementation look like? Would it be enough to use just additional ADO.NET or LINQ etc code or is it worth implementing a custom Membership and/or Profile Provider?
Thank you in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
第一种是最简单的方法。将用户的 GUID 添加为相关表 (fe Ordered_by) 中的外键。我不明白它在哪里打破了分离的关注点。如果你想在数据库中保留订单记录，你还必须保留下订单的用户，这是完全有道理的。
我在当前的应用程序中成功使用了选项 4。我创建了一个表
aspnet_UserID，其中idUser int作为主键，fiUser（aspnet_Users的 GUID）作为外键。这是模型：（注意：
User是标准的aspnet_Users通过 aspnet_regsql.exe 和aspnet_UserId是我的自定义表，它将每个 Guid 与我的 int-ID 映射）现在我只将我的
idUser存储为 FK在所有相关表中（例如在您的订单表中）。这样做的优点是存储空间更少，用户 ID 更易读（我永远记不住 GUID）。也许它与这个“包装表”更加分离，但这不是我的主要意图。如果您愿意，可以更改外键上的删除规则控制行为。如果您想删除要删除的用户订购的所有订单，请将其设置为
Cascade；如果您想保留此订单，请将其设置为no Action。我无法为配置文件问题提出任何替代方案，因为您没有提到“需要以比配置文件提供程序支持的更灵活的方式存储和访问用户配置文件数据”的含义。
The first is the simpliest approach. Add the GUID of the user as a foreignkey in the related tables (f.e. Ordered_by). I don't see where it breaks separating concerns. If you want to keep the order-record in database, you also have to keep the user who has ordered, that makes perfectly sense.
I have used option 4 successfully in my current application. I've created a table
aspnet_UserIDwithidUser intas primary-key and fiUser(the GUID of theaspnet_Users) as foreign-key. Here is the model:(Note:
Useris the standardaspnet_Userstable created via aspnet_regsql.exe andaspnet_UserIdis my custom table that maps every Guid with my int-ID)Now i'm storing only my
idUseras FK in all related tables (like in your Order-Table). That has the advantage of less storage and more readable UserID's(i could never remember a GUID). Maybe it's somewhat more separated with this "wrapper-table" but that was not my main intention.You can change the delete-rule on your foreignkeys if you want to control the behavior. Set it to
Cascadeif you f.e. want to delete all orders that were ordered by the user you're deleting or set it tono Actionif you want to keep this order.I can't suggest any alternatives for the Profile question because you haven't mentioned what you mean with "need to store and access user profile data in more flexible manner then the Profile provider supports".
您应该考虑编写自己的自定义成员资格提供程序，根据您的需要使用表/数据（而不是使用 ASP.NET 提供的架构）。
请参阅此 MSDn 示例（架构、代码) 用于编写自定义提供程序 - 此示例使用 OLEDB 访问数据库。另一个示例位于此处 - 它使用 Active Directory 作为存储。
You should consider writing your own custom membership provider that uses the tables/data as per your need (instead of using ASP.NET provided schema).
See this MSDn sample (schema, code) for writing a custom provider - this sample uses OLEDB to access database. Yet another sample is here - it uses active directory as a store.