ASP.NET 会员资格 - 用于跟踪附加信息的设计
我正在为一个公共站点开发一个 ASP.NET4.0/C# 应用程序，该应用程序只需要对在相关企业工作的员工进行身份验证。这个想法是让网站拥有一个 CMS，以便员工可以进入并更改某些内容，而无需使用任何 html。
我的问题涉及 ASP.NET 会员资格提供程序的设计和使用。我不想让该网站与现有数据库一起使用，因此无需为此目的创建我自己的 MembershipProvider。但是，由于每个用户都是员工，因此我想跟踪其他信息，例如姓名和办公室号码。我可以想到两种显而易见的方法来实现此目的：
使用默认的 SqlMembershipProvider 类。因此，我需要将适当的表添加到我的数据库中，并为我想要存储的任何“附加”信息创建一个单独的表。这有效地在用户表上创建了一个垂直分区，因为我也将使用 asp.net 分配的 userID 作为员工表的主键。要检索“附加”信息，我可以向提供程序询问有关当前用户的信息，并在我想了解其他信息时重新查询数据库。
为所有员工信息（包括登录名和密码）创建一张表，并使用我想要的功能创建我自己的自定义 MembershipProvider 和 MembershipUser 类。
我还考虑过使用个人资料来存储此类信息，但是，该网站将公开包含员工列表，并且这些页面将需要访问其中一些信息。因此，我可能应该缓存这些数据，并且似乎使用配置文件提供的序列化字段会导致问题。
因此，纯粹就设计而言...最好区分用户和员工并使用默认的 SqlMembershipProvider 和关联表，或者编写我自己的用户表来存储我需要的信息和我自己的 MembershipProvider访问该信息？
I'm working on an ASP.NET4.0/C# application for a public site that needs to authenticate only the employees that work at the associated business. The idea is for the site to have a CMS such that employees can go in and make changes to certain content without having to work with any html.
My question relates to the design and use of a ASP.NET membership provider. I'm not trying to make the site work with an existing database, so there's no need to create my own MembershipProvider for that purpose. However, since each user is an employee, I want to track additional information such as name and office number. I can think of two readily apparent ways to accomplish this:
Use the default SqlMembershipProvider class. As a result, I would need to add the appropriate tables to my database and create a separate table for any "additional" information I want to store. This effectively creates a vertical partition on the user table, since I would use the asp.net-assigned userID as the primary key of the employee table as well. To retrieve the "additional" information, I could ask the provider for information about the current user and requery the database in the event I want to know anything else.
Create one table for all employee information (including login and password) and create my own custom MembershipProvider and MembershipUser classes with the functionality I desire.
I've also considered the use of profiles to store such information, however, the site will publicly contain employee listings, and these pages will need to access some of this information. As a result, I should probably cache this data and it seems like using the serialized fields that profiles provide would cause a problem.
Thus, purely in regards to design... would it be best to make a distinction between a user and an employee and use the default SqlMembershipProvider and associated tables, or write my own user tables that store the information I need and my own MembershipProvider for accessing that information?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果我正确理解您的问题，您希望在 ASP.NET 会员资格中存储其他用户信息。我使用以下设置创建了许多网站。
Microsoft 撰写了一篇关于如何操作的优秀文章这。
祝你好运！
M
If I understand your question correctly, you'd like to store additional user info within the ASP.NET Membership. I've created a number of sites using the following setup.
Microsoft has written an excellent post on how to do this.
Good luck!
M
我正在做类似的事情，使用你的选项 1。对我来说效果很好。
我的业务逻辑有一些用于改变用户的功能。它知道何时触摸我的用户表或会员功能。
使用自定义 MembershipProvider 来处理此类事情会给您带来比您预想的更多的工作。
I am doing something similar, using your option 1. Works great for me.
My business logic has some functions for mutating users. It knows when to touch my users table or the Membership functionality.
Using a custom MembershipProvider for this sort of thing will give you more work than you bargained for.
SQL 表配置文件提供程序 (http://weblogs.asp.net /scottgu/archive/2006/01/10/435038.aspx ）将帮助您做到这一点。
您将获得配置文件的强大功能，同时不必担心缓存或序列化，因为该提供程序将配置文件信息存储在清晰的数据库表中，而无需任何序列化。您可以直接在查询中使用它们。
SQL Table profile provider (http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx ) will help you do just that.
You will get the power of the Profiles and on the same time not worry about caching or serialization since this provider stores the profile information in clear database table without any serialization. You can use them directly in your queries.