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

變形精怪發表於2021-02-28

專案地址：https://gitee.com/bxjg1987/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

 

相關文章