决定应用程序中的用户类别位置
我不太确定这一切应该如何运作。因此,我的域模型中有一个聚合(Post
->Feedbacks
;Post
->Category
) 。我一直在考虑 User
类的位置。我的第一个想法是使用状态模式实现 User
类:
interface IUserRole
{
// for example we got something like this:
Boolean CanPost { get; }
Boolean CanEdit { get; }
Boolean CanFlag { get; }
void AssignRole(IUserRole role, User user);
}
public sealed class AdministratorRole : IUserRole
{
public Boolean CanPost { get { return true; } }
public Boolean CanEdit { get { return true; } }
public Boolean CanFlag { get { return true; } }
public void AssignRole(IUserRole role, User user)
{
user.Role = role;
}
}
public sealed class NewMemberRole : IUserRole
{
public Boolean CanPost { get { return true; } }
public Boolean CanEdit { get { return false; } }
public Boolean CanFlag { get { return false; } }
public void AssignRole(IUserRole role, User user)
{
throw new NotSupportedException("text");
}
}
public class User // : Entity<User>
{
private IUserRole role;
public class User(String name, String pwd, IUserRole role)
{
// ...
this.role = role;
}
public Boolean CanPost { get { return this.role.CanPost; } }
public Boolean CanEdit { get { return this.role.CanEdit; } }
public Boolean CanFlag { get { return this.role.CanFlag; } }
public void AssignRole(IUserRole role, User)
{
this.role.AssignRole(role, user);
}
public String Name { get; set; }
public String Password { get; set; }
}
在这一步中,我一直在考虑将 User
包含到域模型中,然后使用它通过 NHibernate DAL/DAO。
我读过有关 MembershipUser
和 MembershipProvider
的内容。所有身份验证内容均在标准 ASP.NET MVC 模板中实现。
因此,如果我使用标准membership/membership-user,域逻辑将去往何处?然后我是否应该通过在操作上设置 Authorize
属性来限制对 Post
实体的操作..以便它们将作为权限工作?
I quite not sure about how it all should work. So I have an aggregate in my domain model (Post
->Feedbacks
;Post
->Category
). And I've been thinking about place of User
class. My first thought was to implement User
class using state pattern:
interface IUserRole
{
// for example we got something like this:
Boolean CanPost { get; }
Boolean CanEdit { get; }
Boolean CanFlag { get; }
void AssignRole(IUserRole role, User user);
}
public sealed class AdministratorRole : IUserRole
{
public Boolean CanPost { get { return true; } }
public Boolean CanEdit { get { return true; } }
public Boolean CanFlag { get { return true; } }
public void AssignRole(IUserRole role, User user)
{
user.Role = role;
}
}
public sealed class NewMemberRole : IUserRole
{
public Boolean CanPost { get { return true; } }
public Boolean CanEdit { get { return false; } }
public Boolean CanFlag { get { return false; } }
public void AssignRole(IUserRole role, User user)
{
throw new NotSupportedException("text");
}
}
public class User // : Entity<User>
{
private IUserRole role;
public class User(String name, String pwd, IUserRole role)
{
// ...
this.role = role;
}
public Boolean CanPost { get { return this.role.CanPost; } }
public Boolean CanEdit { get { return this.role.CanEdit; } }
public Boolean CanFlag { get { return this.role.CanFlag; } }
public void AssignRole(IUserRole role, User)
{
this.role.AssignRole(role, user);
}
public String Name { get; set; }
public String Password { get; set; }
}
On that step I've been considering to include User
into domain model then to use it thru NHibernate DAL/DAO.
I've read about MembershipUser
and MembershipProvider
. And all authentification stuff is implemented in standard ASP.NET MVC
template.
So if I use standard membership/membership-user where will the domain logic go? Should I then restrict operation over Post
entity thru setting Authorize
attribute on actions .. so they will work as permissions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
是的,在 ASP.NET MVC 应用程序中,您可以授权/拒绝某些用户/角色的操作。
它与项目中定义的会员资格提供者一起工作。
.NET 默认附带 2 个成员资格提供程序:一个用于 sqlserver,需要运行一些脚本,另一个基于 ActiveDirectory 成员资格。
您还可以创建自己的
Membership
和Role
提供程序。这样,您就可以为您的域对象/行为定制会员资格提供程序。Yes, in ASP.NET MVC applications, you have the ability to authorize/deny some users/roles on actions.
It works with the membership provider defined in the project.
.NET is shipped by default with 2 membership providers: one for sqlserver, with some scripts to run, and another one based on ActiveDirectory membership.
You can also make your own
Membership
andRole
providers. This way you'll have the membership provider customized for your domain objects/behavior.