多层架构和身份。为什么要使用 UserManager 和 RoleManager?
Multitier architecture and Identity. Why to use UserManager and RoleManager?
Microsoft Identity 引入了 UserManager<T>
和 RoleManager<T>
classes 以与 AspNetUsers
、AspNetRoles
和其他数据库表进行交互。但是我们为什么要使用它们呢?也许更好的解决方案是搭建数据库并直接使用 Entity Framework 处理其表,而忘记 classes UserManager<T>
和 RoleManager<T>
?
我为什么要问?
我的申请我要按照multitier architecture。
我开始为用户创建 DTO-class:
public class UserDto
{
public string Id { get; set; }
public string UserName { get; set; }
...
public List<RoleDto> Roles { get; set; }
}
public class RoleDto
{
public string Id { get; set; }
public string Name { get; set; }
...
}
键入 IdentityUser
我想 map 到 UserDto
,键入 IdentityRole
- 到 RoleDto
.
如您所见,我想在 UserDto
中存储用户的角色。
现在让我们看一下 IdentityUser
类型:link。
它包含很多属性,但它没有用户角色。
因此,当将 IdentityUser
映射到 UserDto
时,我需要使用 RoleManager<T>
来获取用户的角色。我认为,这是一个肮脏的解决方案。
我的想法
我们可以忘记 UserManager<T>
和 RoleManager<T>
类型。我们可以简单地 scaffold 数据库并使用 Entity Framework.
来处理它
在搭建数据库后,我有以下内容:
public partial class AspNetUser
{
public string Id { get; set; }
public string UserName { get; set; }
public string NormalizedUserName { get; set; }
public string Email { get; set; }
public string NormalizedEmail { get; set; }
public bool EmailConfirmed { get; set; }
public string PasswordHash { get; set; }
public string SecurityStamp { get; set; }
public string ConcurrencyStamp { get; set; }
public string PhoneNumber { get; set; }
public bool PhoneNumberConfirmed { get; set; }
public bool TwoFactorEnabled { get; set; }
public DateTimeOffset? LockoutEnd { get; set; }
public bool LockoutEnabled { get; set; }
public int AccessFailedCount { get; set; }
public virtual ICollection<AspNetUserClaim> AspNetUserClaims { get; set; }
public virtual ICollection<AspNetUserLogin> AspNetUserLogins { get; set; }
public virtual ICollection<AspNetUserRole> AspNetUserRoles { get; set; }
public virtual ICollection<AspNetUserToken> AspNetUserTokens { get; set; }
}
// AspNetUserClaim, AspNetUserLogin, AspNetUserRole and AspNetUserToken
我只介绍了AspNetUser class 简而言之。如您所见,它有一个 属性 AspNetUserRoles - 用户角色。这很棒,因为现在将 class 映射到 UserDto
.
真的很简单
问题
搭建数据库而不使用 UserManager
和 RoleManager
classes 是个好主意吗?
也许你可以介绍一个更好的解决方案?
您为什么认为这是个好主意?通过重写像身份这样的东西你会得到什么?
来自Introduction to Identity on ASP.NET Core
ASP.NET Core Identity:
Is an API that supports user interface (UI) login functionality.
Manages users, passwords, profile data, roles, claims, tokens, email confirmation, and more.
这不仅仅是数据库访问。它还是管理登录功能、安全令牌创建、安全密码管理等的代码。
如果您创建自定义系统,您需要考虑以上所有因素,让外部审计员对您的解决方案进行渗透测试(尽管无论您做出什么选择,这都是一个好主意)、单元测试、性能测试等
以上都已经完成了。您也可以使用各种挂钩点轻松自定义身份。
顺便说一句,默认情况下身份已经使用 ef 访问数据存储。
构建您的多层应用程序,但将身份排除在外。这是一个横向关注点,它的存在是为了简化您的开发,让您只担心您的业务需求。
Microsoft Identity 引入了 UserManager<T>
和 RoleManager<T>
classes 以与 AspNetUsers
、AspNetRoles
和其他数据库表进行交互。但是我们为什么要使用它们呢?也许更好的解决方案是搭建数据库并直接使用 Entity Framework 处理其表,而忘记 classes UserManager<T>
和 RoleManager<T>
?
我为什么要问?
我的申请我要按照multitier architecture。 我开始为用户创建 DTO-class:
public class UserDto
{
public string Id { get; set; }
public string UserName { get; set; }
...
public List<RoleDto> Roles { get; set; }
}
public class RoleDto
{
public string Id { get; set; }
public string Name { get; set; }
...
}
键入 IdentityUser
我想 map 到 UserDto
,键入 IdentityRole
- 到 RoleDto
.
如您所见,我想在 UserDto
中存储用户的角色。
现在让我们看一下 IdentityUser
类型:link。
它包含很多属性,但它没有用户角色。
因此,当将 IdentityUser
映射到 UserDto
时,我需要使用 RoleManager<T>
来获取用户的角色。我认为,这是一个肮脏的解决方案。
我的想法
我们可以忘记 UserManager<T>
和 RoleManager<T>
类型。我们可以简单地 scaffold 数据库并使用 Entity Framework.
来处理它
在搭建数据库后,我有以下内容:
public partial class AspNetUser
{
public string Id { get; set; }
public string UserName { get; set; }
public string NormalizedUserName { get; set; }
public string Email { get; set; }
public string NormalizedEmail { get; set; }
public bool EmailConfirmed { get; set; }
public string PasswordHash { get; set; }
public string SecurityStamp { get; set; }
public string ConcurrencyStamp { get; set; }
public string PhoneNumber { get; set; }
public bool PhoneNumberConfirmed { get; set; }
public bool TwoFactorEnabled { get; set; }
public DateTimeOffset? LockoutEnd { get; set; }
public bool LockoutEnabled { get; set; }
public int AccessFailedCount { get; set; }
public virtual ICollection<AspNetUserClaim> AspNetUserClaims { get; set; }
public virtual ICollection<AspNetUserLogin> AspNetUserLogins { get; set; }
public virtual ICollection<AspNetUserRole> AspNetUserRoles { get; set; }
public virtual ICollection<AspNetUserToken> AspNetUserTokens { get; set; }
}
// AspNetUserClaim, AspNetUserLogin, AspNetUserRole and AspNetUserToken
我只介绍了AspNetUser class 简而言之。如您所见,它有一个 属性 AspNetUserRoles - 用户角色。这很棒,因为现在将 class 映射到 UserDto
.
问题
搭建数据库而不使用 UserManager
和 RoleManager
classes 是个好主意吗?
也许你可以介绍一个更好的解决方案?
您为什么认为这是个好主意?通过重写像身份这样的东西你会得到什么?
来自Introduction to Identity on ASP.NET Core
ASP.NET Core Identity:
Is an API that supports user interface (UI) login functionality.
Manages users, passwords, profile data, roles, claims, tokens, email confirmation, and more.
这不仅仅是数据库访问。它还是管理登录功能、安全令牌创建、安全密码管理等的代码。
如果您创建自定义系统,您需要考虑以上所有因素,让外部审计员对您的解决方案进行渗透测试(尽管无论您做出什么选择,这都是一个好主意)、单元测试、性能测试等
以上都已经完成了。您也可以使用各种挂钩点轻松自定义身份。
顺便说一句,默认情况下身份已经使用 ef 访问数据存储。
构建您的多层应用程序,但将身份排除在外。这是一个横向关注点,它的存在是为了简化您的开发,让您只担心您的业务需求。