如何将我的应用程序数据与 ASP.NET MemberShipProvider 中的用户关联？
我刚刚开始学习 ASP.NET MVC。我正在开发一个使用标准项目模板创建的项目，该模板默认使用 SqlMembershipProvider。这会在我的项目中自动创建一个 ASPNETDB.mdf 数据库来保存成员资格信息。如何将存储在该数据库中的成员与我的实际应用程序数据关联起来？
在我的应用程序数据库中存储或检索用户特定信息时，是否应该使用 this.User.Identity.Name 在操作方法中简单地引用当前用户的名称作为键？或者我应该使用 this.User.Identity.UserId 来代替？我一直认为基于整数的 ID 比字符串或 GUID 基本 ID 的查找速度要快得多。但 aspnet_Users 表的主键是 GUID 字段。
this.user 与 this.HttpContext.User 之间有什么区别吗？从这些属性返回的 IPrincipal 与从 Membership.GetUser() 返回的 MembershipUser 又如何呢？这些有什么区别呢？
另外，最好将会员信息保存在与应用程序数据库不同的数据库中吗？或者可以将它们合并到一个数据库中吗？
I'm just starting out learning ASP.NET MVC. I'm working on a project created with the standard project template which by default uses a SqlMembershipProvider. This has automatically created a ASPNETDB.mdf database in my project to hold membership information. How can I associate the members stored in this database with my actual application data?
Should I simply reference the current user's name in my action methods using this.User.Identity.Name to use as a key when storing or retrieving user specific information to and from my application's database? Or should I be using this.User.Identity.UserId instead? I always thought integer based IDs were much faster to look up vs string or GUID base IDs. But the primary key of the aspnet_Users table is a GUID field.
Is there any difference between this.user vs this.HttpContext.User? What about the IPrincipal returned from these properties vs the MembershipUser returned from Membership.GetUser(). What is the difference between these?
Also, is it best to keep the membership information in a separate database from the application database? Or is it ok to merge them together into a single database?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您的问题有几个要素，几点：
我通常使用身份名称，因为它通常使用起来更有效。 获取用户函数获取完整的数据库中的用户数据并更新上次访问时间。 IPrinciple 不需要这个并在内存数据中使用。因此，用户名属性更快且更容易使用。主要需要注意的是，您是否允许用户更改其用户名，在这种情况下，ID 会更有意义。
听起来您正在考虑拥有大量与用户相关的记录。你是对的，整数是最快查找的。如果您有大量数据，那么您可能希望通过 扩展成员资格 提供程序或通过添加映射表。
至于 this.User 与 HttpContext.User ，没有区别。
There's a few elements to your question, a few points:
I normally use the identity name as it's typically more efficient to use. The get user function gets the full user data from the database and updates the last access time. The IPrinciple doesn't require this and uses in memory data. As such the username property is quicker and more readily available. The main caveat would be if you might allow users to change their user name, in which case the ID would make more sense.
It sounds like you are making considerations for having a lot of user related records. You are right, integers are the quickest to look up. If you have large volumes of data then you might want to map your users to an integer, either by extending the membership provider or by adding a mapping table.
As for the this.User vs HttpContext.User, no difference.
默认模板应该在 Models 文件夹中为您提供一个“AccountModel”，它为某些表单验证/成员资格函数创建包装器。您可以对此进行扩展并添加一个函数来返回当前的“HttpContext.Current.User”，它是存储在当前 HttpContext 中的 IPrincipal。使用 Name 属性，您可以通过用户名查询会员资格以获取会员资格数据（IPrincipal 仅存储非常基本的信息，例如用户名、角色等，MembershipUser 拥有从数据库中提取的所有其他数据）。
在我看来，SqlMembershipProvider 非常糟糕，并且除了小型项目之外还有其他限制......同时又太复杂了。我现在在一个拥有 2000 多个帐户的网站上使用它，如果你想自定义任何东西，它就是一个皮塔饼。最好（网上有很多例子）编写自己的使用表单身份验证并摆脱会员资格的废话。我现在有一个，我希望我一开始就写一个。
The default template should give you an "AccountModel" in the Models folder which creates wrappers for some of the formsauthentication/membership functions. you can extend on that and add a function to return the current "HttpContext.Current.User" which is an IPrincipal stored in the current HttpContext. With the Name property from that you could query Membership by username to get the Membership data (the IPrincipal just stores the very basics such as username,roles,etc the MembershipUser has all the other data pulled from the db).
The SqlMembershipProvider is pretty crappy imo and limiting other than for small projects...and at the same time waay to complicated. I'm using it now on a site with 2000+ accounts and it's a pita if you want to customize anything. It's better off (and there is lots of examples on the net) just to write your own that uses formsauthentication and get rid of the Membership crap. I have one now I wish I wrote one to begin with.
在我使用 SqlMembershipProvider 的应用程序中，我通常将其表/存储过程存储在与我的应用程序表相同的数据库中，然后使用外键将我的应用程序表链接到用户表。我有一次没有这样做，是当一个用户数据库将在多个不同的应用程序之间共享时，每个应用程序都有自己的应用程序数据库。
In apps where I have used SqlMembershipProvider, I have typically stored its tables/sprocs in the same DB as my application tables and then linked my app tables to the user tables using a foreign key. The one time I didn't do it this way was when one user database was going to be shared between multiple distinct applications that each had their own app database.