abp中多種登陸使用者的設計

場景

在《學校管理系統》中，學生、家長、教師、教務都可能登陸，做一些屬于他們自己的操作。這些使用者需要的屬性各不相同，比如學生有學号，而教師沒有。

應用程式使用者

在編碼時，經常需要擷取目前登陸使用者的資訊，這個目前登陸使用者就是應用程式使用者。asp.net提供了一整套方案來實作應用程式使用者，包括身份驗證、授權、asp.net identity等

應用程式使用者與業務場景中的使用者不同，應用程式使用者隻需要差別是誰，最簡單情況隻需要知道使用者id，它不關心這個使用者具體是教師還是學生或其它類型的使用者。基于這個使用者id還可以實作角色、授權等操作。 淺顯點了解應用程式使用者主要是識别使用者id，友善實作角色和授權

而“學生”、“教師”則是《學校管理系統》這個場景中的具體業務概念。

abp中有個abp zero子產品,它已實作應用程式使用者管理、登陸、角色、授權等功能。

與abp使用者一對一關聯

當業務使用者需要登陸時，一對一關聯到應用程式使用者。*

這樣系統本身提供的登陸、登出、角色、授權等功能幾乎保持不變，按需要可以實作多種業務使用者類型。

子產品化

我們的系統是按業務分子產品開發的，參考：https://www.bilibili.com/video/BV1b5411L7Hf/

有些業務子產品可能存在業務使用者，比如【商城子產品】中的“顧客”，在設計時需要考慮子產品化和可擴充性。

由于是獨立子產品，是以我們不知道将來子產品被什麼系統引用，是以也不知道具體的AbpUser類型，因為那是子產品使用方自己定義的，是以在開發業務子產品時不應該出現具體的AbpUser的類型，需要關聯時隻能關聯Id，必要時可以引用抽象的AbpUser及其管理類。

Core層

按ddd和abp的方式這層需要建立：聚合根、實體、值對象、領域服務、領域事件、倉儲接口。

下面以《學校管理系統》場景說明

實體

按ddd方式定義學生實體（它應該是聚合根）。

定義學号、所屬學院、所屬專業等屬性，重點是它有個UserId屬性，關聯到應用程式使用者，注意不要使用導航屬性關聯到AbpUser，一來ddd建議一個聚合中的實體不要使用導航屬性關聯到另一個聚合中的實體，二來我們使用的是子產品化開發方式，我們在開發自己的子產品時并不會知道子產品将來被誰使用，是以就不會知道具體的類型，因為在abp中，使用者是由開發人員自定義的。

不要考慮子產品使用方使用繼承來擴充實體，建議使用abp提供的IExtensionObject接口或動态屬性系統。

領域實體中可以觸發事件，以便子產品調用方擴充

領域服務、領域事件、倉儲接口。

這個根據需要決定是否定義。

領域服務可以提供虛方法以便子產品使用方法提供子類重寫，也可以觸發相應事件讓子產品使用方去訂閱。

由于将來可能增加更多使用者類型，領域服務可以考慮抽象封裝在BXJG.Utils（依賴abp的通用功能子產品）中

EFCore層

ef映射和種子資料的處理

Application層

新增業務使用者時考慮同時建立并關聯使用者、删除時則一并删除。

可以提供虛方法，以便子產品調用方繼承并重寫

在子產品中，沒有将新增、删除應用程式使用者的邏輯預留給子產品使用方，而是在子產品内部直接做了，子產品調用方可以訂閱UserCreating、UserDeleting事件來插入自己的邏輯

由于将來可能增加更多使用者類型，應用服務可以考慮抽象封裝在BXJG.Utils.Application中

session與登陸

如《學生管理系統》有個學生背景，裡面全都是學生可以操作的功能，做這些功能時通常需要擷取目前登陸學生的id。abp的seession功能隻能擷取目前登陸使用者id，這是abpUser的id，這個id并不是我們需要的，它與學生實體是一對一關聯的。

我們可以通過abp的seesion擷取目前abpUser的id，然後去對應使用者表查詢得到業務使用者的id，但這樣比較浪費性能。

我們的思路是在使用者登陸時将關聯的業務場景使用者的id存儲到claim中，然後提供一個類似abpsession的session來在需要是提供目前業務使用者的id

我們可以為每種使用者建立登陸頁面，在登陸時存儲業務使用者id到claim中，也可以在統一的登陸頁面加各判斷，然後擷取對應業務使用者類型表中的業務使用者id

session的設計也可以抽象出來，因為有多種使用者類型

如何使用

abp官方文檔教程中有[擴充session](https://aspnetboilerplate.com/Pages/Documents/Articles%5CHow-To%5Cadd-custom-session-field-aspnet-core)的說明，我們也是按這個思路做的。由于系統可能存在多種業務使用者，是以需要簡單封裝下，下面看看商城子產品中的顧客是如何實作session和登陸的

實體實作IBusinessUserEntity

1 public class CustomerEntity : FullAuditedAggregateRoot<long>, IBusinessUserEntity , IMustHaveTenant, IExtendableObject
2 //略....      

定義session接口和實作 

1 public interface ICustomerSession : IBusinessUserSession<long>{}
 2 
 3 public class CustomerClaimSession : BusinessUserClaimSession<long>, ICustomerSession
 4 {
 5     public CustomerClaimSession(IPrincipalAccessor principalAccessor,
 6     IMultiTenancyConfig multiTenancy,
 7     ITenantResolver tenantResolver,
 8     IAmbientScopeProvider<SessionOverride> sessionOverrideScopeProvider) :         base(principalAccessor, multiTenancy, tenantResolver,     sessionOverrideScopeProvider, CoreConsts.CustomerIdClaim)
 9     {
10     }
11 }          

在子產品中實作ioc注入

1 public override void Initialize()
2 {
3      IocManager.IocContainer.Register(Component.For<ICustomerSession>()
4      .ImplementedBy<CustomerClaimSession>()
5      .LifestyleCustom<MsScopedLifestyleManager>()
6      .Named("sdf234sdf"));//CustomerClaimSession的父類已單例注冊了，需要重命名下
7 
8 }      

定義登陸器接口和實作

public interface ICustomerLoginManager<TUser> : IBusinessUserLoginManager<TUser> { }

/// <summary>
/// 提供與顧客登陸相關功能
/// </summary>
public class CustomerLoginManager<TTenant,
    TRole,
    TUser,
    TUserManager> : BusinessUserLoginManager<CustomerEntity,
                long,
                TTenant,
                TRole,
                TUser,
                TUserManager>, ICustomerLoginManager<TUser>
where TTenant : AbpTenant<TUser>
where TRole : AbpRole<TUser>, new()
where TUser : AbpUser<TUser>
where TUserManager : AbpUserManager<TRole, TUser>
{
        public CustomerLoginManager(IRepository<CustomerEntity, long> repository,
TUserManager userManager) : base(repository,
userManager,
CoreConsts.CustomerRoleName,
CoreConsts.CustomerIdClaim)
{ }
}                              

主程式的XXX.Core的Module類中添加依賴注入

1 IocManager.Register<ICustomerLoginManager<User>, CustomerLoginManager<Tenant, Role, User, UserManager>>(Abp.Dependency.DependencyLifeStyle.Transient);      

使用登陸器

最後在主程式的UserClaimsPrincipalFactory中

1  public class UserClaimsPrincipalFactory : AbpUserClaimsPrincipalFactory<User, Role>
 2   {
 3     private readonly ICustomerLoginManager<User> customerLoginManager;
 4     public UserClaimsPrincipalFactory(
 5     UserManager userManager,
 6     RoleManager roleManager,
 7     IOptions<IdentityOptions> optionsAccessor, ICustomerLoginManager<User>         customerLoginManager)
 8     : base(
 9     userManager,
10     roleManager,
11     optionsAccessor)
12     {
13     this.customerLoginManager = customerLoginManager;
14     }
15     public override async Task<ClaimsPrincipal> CreateAsync(User user)
16     {
17     var claim = await base.CreateAsync(user);
18     var c = await customerLoginManager.GetBusinessUserClaim(user);
19     if(c!=null)
20 claim.Identities.First().AddClaim(c);
21         return claim;
22     }
23 }      

流程說明

登陸時AbpLoginManager會調用UserClaimsPrincipalFactory來向目前登陸使用者的Claims中插入Claim

UserClaimsPrincipalFactory會調用ICustomerLoginManager，先判斷使用者是否是顧客的角色，若是則根據使用者Id找到顧客Id，然後将顧客Id存儲到Claims中

後續我們在需要擷取目前登陸的顧客的id時在我們的服務中依賴注入ICustomerSession就可以了，它會從目前登陸使用者的Claims中去找到顧客id

源碼

完整源碼參考：商城子產品中顧客的實作

用支付寶掃一掃，咱倆都可以獲得一個小紅包

關注我的今日頭條，有不錯的c#.net經驗分享

本文來自部落格園，作者：變形精怪，轉載請注明原文連結：https://www.cnblogs.com/jionsoft/p/14457946.html