我是网络开发的新手。现在我用ASP.NET Identity学习ASP.NET MVC 5。 你能否在我的情况下给我一些建议:
在我的网站中,我希望拥有某些类型的用户。例如: 买方 卖方
他们每个人都可以登录并控制他的部分信息。(例如,买家可以更改他的信息,添加请求。卖家也可以更改自己的信息并添加商品)
现在,我创造了类似的东西:
using Microsoft.AspNet.Identity.EntityFramework;
using System.Data.Entity;
public class ApplicationUser : IdentityUser
{
public int? BuyerId { get; set; }
public int? SellerId { get; set; }
public virtual Buyer Buyer { get; set; }
public virtual Seller Seller { get; set; }
}
public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("DefaultConnection")
{
}
...
}
当我们创建一个用户时,他会获得一些带有信息的角色和财产(例如,如果是买方,他将拥有角色“买方”和一些买方财产(并且卖方将为空)。
这是正常的做法吗?
更新
我认为我选择了一个糟糕的例子(与卖方和买方合作)。在我的情况下,我有一些像recomendation系统(另一个例子):
系统可以根据有关用户的其他信息(例如最近的经验等)和项目(例如种类,成本等)来确定用户的偏好(一些蔬菜或水果)
答案 0 :(得分:11)
没有。这不是你想要处理的方式。用户是用户。如果你在能力方面有真正的区别,你可以使用角色,但在大多数系统中,如你所描述的,作为“买家”或“卖家”并不是真正的黑白分明的东西:购买东西的人,可能最终喜欢卖,而卖家可能真的想买东西。我的建议是不要做任何区分。如果您想在某人可以出售之前进行一些审批流程,那么您可以再次使用“卖家”角色,只有那些已添加到该角色的人才会看到卖家选项。
如果您需要存储作为买方或卖方独有的信息,那么您还可以使用声明,这比向用户模型添加其他属性要灵活得多,而且创建实际的外键关系肯定要灵活得多存储额外数据。
答案 1 :(得分:0)
你应该看看Membership-和RoleProviders,Microsofts处理这个问题的标准方法。
然后,您可以选择以下两个选项之一。
如果您已在自定义系统中拥有大量用户和角色,那么您可能需要考虑编写自定义成员资格和角色提供程序,这些成员资格和角色提供程序可以将您现有的用户和角色映射到您希望在现场。 See an example of this here.