如何将 Membership API 与自己的应用程序相关数据结合使用? [英] How to combine using Membership API with own application related data?
问题描述
在 asp.net 4 中设计新应用程序 我必须决定如何使用 MS SQL Membership API 以及我自己在 MS SQL 数据库中的数据.首先，我需要以更灵活的方式存储和访问用户配置文件数据，然后配置文件提供程序支持.其次，我想链接其他用户相关信息(例如订单).
无论您将 aspnetdb 表存储在何处(在单独的数据库中或与数据位于同一数据库中)，问题仍然是如何保持数据同步.
经过研究，我看到以下相关选项:
1. 来自 asp_Users 的外键 UserId(建议在 和 aspnet_UserId 是我的自定义表，将每个 Guid 与我的 int-ID 映射)
现在我只将我的 idUser 作为 FK 存储在所有相关表中(例如在您的订单表中).这具有更少存储空间和更易读的 UserID(我永远记不起 GUID)的优点.也许它与这个包装表"更加分离，但这不是我的主要意图.
您可以更改外键上的删除规则，如果你想控制行为.如果您不喜欢，请将其设置为 Cascade想要删除您要删除的用户订购的所有订单，或者如果您想保留此订单，请将其设置为 no Action.
我无法为 Profile 问题提出任何替代方案，因为您没有提到需要以比 Profile 提供程序支持的方式更灵活的方式存储和访问用户配置文件"的意思.
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.
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_UserID with idUser int as primary-key and fiUser(the GUID of the aspnet_Users) as foreign-key. Here is the model:
(Note: User is the standard aspnet_Users table created via aspnet_regsql.exe and aspnet_UserId is my custom table that maps every Guid with my int-ID)
Now i'm storing only my idUser as 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 Cascade if you f.e. want to delete all orders that were ordered by the user you're deleting or set it to no Action if 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".
这篇关于如何将 Membership API 与自己的应用程序相关数据结合使用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
