程式師世界 >> 編程語言 >> .NET網頁編程 >> ASP.NET >> ASP.NET基礎 >> 詳解ABP框架中的數據過濾器與數據傳輸對象的使用

詳解ABP框架中的數據過濾器與數據傳輸對象的使用

編輯：ASP.NET基礎

數據過濾器（Data filters）
在數據庫開發中，我們一般會運用軟刪除(soft-delete)模式,即不直接從數據庫刪除數據,而是標記這筆數據為已刪除。因此,如果實體被軟刪除了,那麼它就應該不會在應用程序中被檢索到。要達到這種效果,我們需要在每次檢索實體的查詢語句上添加SQL的Where條件IsDeleted = false。這是個乏味的工作，但它是個容易被忘掉的事情。因此,我們應該要有個自動的機制來處理這些問題。

ABP提供數據過濾器(Data filters),它使用自動化的，基於規則的過濾查詢。ABP已經有一些預定義的過濾器,當然也可以自行創建你專屬的過濾器。

注意：只針對EntityFramework:ABP數據過濾器僅實現在EntityFramework。還無法在其它ORM工具中使用。見其它ORM章節於本文末端。

預定義過濾器
1.軟刪除接口(ISoftDelete)

軟刪除過濾器(Soft-delete filter )會過濾從數據庫查詢出來的實體且是自動套用(從結果集中提取出來)。如果實體需要被軟刪除,它需要實現ISoftDelete接口,該接口僅定義了一個IsDeleted屬性。例:

 public class Person : Entity, ISoftDelete {
 public virtual string Name { get; set; }
 public virtual bool IsDeleted { get; set; }
 }

Person實體實際上並沒有從數據庫中被刪除,當刪除此實體時,IsDeleted屬性值會被設定為true。當你使用IRepository.Delete方法時,ABP會自動完成這些工作(你可以手動設定IsDeleted為true,但是Delete方法更加自然且是較建議的方式)。

當實現了ISoftDelete之後,當你已經從數據庫中取得了People列表,已被刪除的People實體並不會被檢索到。在這裡有一個示例類,該類使用了person倉儲來取得所有的People實體:

 public class MyService {
 private readonly IRepository<Person> _personRepository;

 public MyService(IRepository<Person> personRepository) {
  _personRepository = personRepository;
 }

 public List<Person> GetPeople() {
  return _personRepository.GetAllList();
 }
 }

GetPeople方法僅取得Person實體,該實體其IsDeleted = false(非刪除狀態)。所有的倉儲方法以及導航屬性都能夠正常運作。我們可以添加一些其它的Where條件,Join...等等。它將會自動地添加IsDeleted=false條件到生成的SQL查詢語句中。

注意：何時啟用?ISoftDelete過濾器總是啟用,除非你直接禁用它。

提醒:如果你實現了IDeletionAudited接口(該接口繼承自ISoftDelete),刪除創建時間和被刪除的用戶Id，這些都會由ABP進行自動的處理。

2.多租接口(IMustHaveTenant)

如果你創建一個多租戶的應用程序(儲存所有租戶的數據於單一一個數據庫中),你肯定不會希望某個租戶看到其它租戶的資料。你可以實現IMustHaveTenant接口於此案例中,示例如下:

 public class Product : IMustHaveTenant {
 public virtual int TenantId { get; set; }

 public virtual string Name { get; set; }
 }

IMustHaveTenant定義了TenantId來區別不同的租戶實體。ABP使用IAbpSession來取得當前TenantId並且自動地替當前租戶進行過濾查詢的處理。

注意：何時啟用?IMustHaveTenant默認是啟用的。如果當前使用並沒有登入到系統或是當前用戶是一個管理級使用者(管理級使用者即為一個最高權限的使用者,它可以管理所有租戶和租戶的資料),ABP會自動地禁用IMustHaveTenant過濾器。因此,所有的租戶的數據都可以被應用程序所檢索。注意,這與安全性無關,你應該要對敏感數據進行驗證授權處理。

3.多租接口(IMayHaveTenant)

如果一個實體類由多個租戶(tenant)以及管理級使用者(host)所共享(這意味著該實體對象或許由租戶(tenant)或是管理級使用者(host)所掌控),你可以使用IMayHaveTenantfilter。IMayHaveTenant接口定義了TenantId但是它是可空類(nullable)。

 public class Product : IMayHaveTenant {
 public virtual int? TenantId { get; set; }

 public virtual string Name { get; set; }
 }

當為null值,則代表這是一個管理級使用者(host)所掌控的實體,若為非null值,則代表這個實體是由租戶(tenant)所掌控,而其Id值即為TenantId。ABP使用IAbpSession接口來取得當前TenantId。IMayHaveTenant過濾器並不如IMustHaveTenant普遍常用。但是當作為管理級使用者(host)和租戶(tenant)所需要的通用結構使用時,你或許會需要用到它。

何時啟用?IMayHaveTenant接口總是啟用的,除非你直接禁用它。

禁用過濾器
可以在工作單元(unit of work)中調用DisableFilter方法來禁用某個過濾器,如下所示:

var people1 = _personRepository.GetAllList();
using(_unitOfWorkManager.Current.DisableFilter(AbpDataFilters.SoftDelete)) {
 var people2 = _personRepository.GetAllList();
 }

var people3 = _personRepository.GetAllList();

DisableFilter方法取得一或多個過濾器名稱,且類型皆為string。AbpDataFilters.SoftDelete是一個常數字符串其包含了ABP標准的軟刪除過濾器。

people2亦可取得已標記為刪除的People實體,而people1和people3將會是唯一的非已標記為刪除的People實體。若配合使用using語法,你可以禁用其控制范圍內(Scope)的過濾器。如果你不使用 using 語法 ,此過濾器會被一直禁用，直到工作單元（unit of work）結束或者再度啟用它。(意思是：如果你使用"using"關鍵字聲明,過濾器是啟用狀態；當前工作單元(unit of work)結束後，過濾器是禁止狀態。如果不使用"using"關鍵字聲明，默認過濾器是禁用狀態，此時可以手動啟用過濾器。)

你可以注入IUnitOfWorkManager並且在上述示例中使用。同樣的,你可以使用CurrentUnitOfWork屬性作為一個在應用服務中的簡便方式(它是從ApplicationService類繼承而來的)。

注意：關於using語法:假如過濾器在你調用DisableFilter方法並配合using語法之前已是啟用,則過濾器會被禁用,並且會自動地在using語法結束後在度啟用。但是若過濾器在using語法之前就已經被禁用了,DisableFilter方法實際上並不做任何式,並且過濾器會維持禁用狀態即便是using語法的結束後。

啟用過濾器
你可以在工作單元(unit of work)中使用EnableFilter方法啟用過濾器,如同DisableFilter方法一般(兩者互為正反兩面)。EnableFilter亦會返回disposable來自動地重新禁用過濾器。

設定過濾器參數
過濾器可以被參數化(parametric)。IMustHaveTenant過濾器是這類過濾器的一個范本,因為當前租戶(tenant)的Id是在執行時期決定的。對於這些過濾器,如果真有需要,我們可以改變過濾器的值。舉例如下:

CurrentUnitOfWork.SetFilterParameter("PersonFilter", "personId", 42);
另一個示例如下:設定IMayHaveTenant過濾器的tenantId值:

CurrentUnitOfWork.SetfilterParameter(AbpDataFilters.MayHaveTenant, AbpDataFilters.Parameters.TenantId, 42);

自定義過濾器
欲創建定制的過濾器並且整合到ABP中,首先我們需要定義一個接口,該接口將會由使用這個過濾器的實體所實現。假設我們想要自動化地依PersonId進行過濾,示例如下:

 public interface IHasPerson {
 int PersonId { get; set; }
 }

然後我們就可以實現這個接口在我們的實體上了,示例如下:

 public class Phone : Entity, IHasPerson {
 [ForeignKey("PersonId")]
 public virtual Person Person { get; set; }

 public virtual int PersonId { get; set; }

 public virtual string Number { get; set; }
 }

因為ABP使用EntityFramework.DynamicFilters這個過濾器,我們使用它的規則(rule)來定義過濾器。在我們的DbContext類中,我們重寫了OnModelCreating並且定義了過濾器如下示例所示:

 protected override void OnModelCreating(DbModelBuilder modelBuilder) {
 base.OnModelCreating(modelBuilder);
 modelBuilder.Filter("PersonFilter", (IHasPerson entity, int personId) => entity.PersonId == personId, 0 );
 }

PersonFilter過濾器在這裡是一個唯一的過濾器名稱。再來就是過濾器接口的參數定義和personId過濾器參數(不一定需要,假如過濾器是屬於不可參數化(parametric)型),最後一個參數為personId的默認值。

最後一個步驟,我們需要注冊這個過濾器到ABP工作單元(unit of work)系統中,設定的位置在我們模塊裡的PreInitialize方法。

Configuration.UnitOfWork.RegisterFilter("PersonFilter", false);

第一個參數是我們剛剛所定義的唯一名稱,第二個參數指示這個過濾器預設是啟用還是禁用。在聲明完這些可參數化(parametric)的過濾器後,我們可以在執行期間指定它的值來操作這個過濾器。

 using(CurrentUnitOfWork.EnableFilter("PersonFilter")) {
 CurrentUnitOfWork.SetFilterParameter("PersonFilter", "personId", 42);
 var phone = _phoneRepository.GetAllList();
 // ...
 }

我們可以從有些數據源中取得personId而不需要寫死在程序代碼中。上述示例是為了要能夠程序化過濾器。過濾器可擁有0到更多的參數。假如是無參數的過濾器,它就不需要設定過濾器的值。同樣地,假如它預設是啟用,就不需要手動啟用(當然的,我們也可以禁用它)。

EntityFramework.DynamicFilters的文件:若需要更多關於動態數據過濾器的相關信息,可以見其在git上的文件https://github.com/jcachat/EntityFramework.DynamicFilters

我們可以為安全性創建一個定制化的過濾器,主/被動實體,多租戶...諸如此類的。

其它對象關系映射工具
ABP數據過濾器僅實現在Entity Framework上。對於其它ORM工具則尚不可用。但是, 實際上,你可以模仿這個模式到其它使用倉儲來取得數據的案例下。這此案例中, 你可以創建一個定制的倉儲並且覆寫GetAll方法,如果有需要的話,可以一起修改其它資料檢索方法。

數據傳輸對象（DTOs）
數據傳輸對象(Data Transfer Objects)用於應用層和展現層的數據傳輸。

展現層傳入數據傳輸對象(DTO)調用一個應用服務方法，接著應用服務通過領域對象執行一些特定的業務邏輯並且返回DTO給展現層。這樣展現層和領域層被完全分離開了。在具有良好分層的應用程序中，展現層不會直接使用領域對象(倉庫，實體)。

數據傳輸對象的作用
為每個應用服務方法創建DTO看起來是一項乏味耗時的工作。但如果你正確使用它們，這將會解救你的項目。為啥呢？

1.抽象領域層 (Abstraction of domain layer)

在展現層中數據傳輸對象對領域對象進行了有效的抽象。這樣你的層(layers)將被恰當的隔離開來。甚至當你想要完全替換展現層時，你還可以繼續使用已經存在的應用層和領域層。反之，你可以重寫領域層，修改數據庫結構，實體和ORM框架，但並不需要對展現層做任何修改，只要你的應用層沒有發生改變。

2.數據隱藏 (Data hiding)

想象一下，你有一個User實體擁有屬性Id, Name, EmailAddress和Password。如果UserAppService的GetAllUsers()方法的返回值類型為List。這樣任何人都可以查看所有人的密碼，即使你沒有將它打印在屏幕上。這不僅僅是安全問題，這還跟數據隱藏有關。應用服務應只返回展現層所需要的，不多不少剛剛好。

3.序列化 & 惰性加載 (Serialization & lazy load problems)

當你將數據(對象)返回給展現層時，數據有可能會被序列化。舉個例子，在一個返回Json的MVC的Action中，你的對象需要被序列化成JSON並發送給客戶端。直接返回實體給展現層將有可能會出現麻煩。

在真實的項目中，實體會引用其他實體。User實體會引用Role實體。所以，當你序列化User時，Role也將被序列化。而且Role還擁有一個List並且Permission還引用了PermissionGroup等等….你能想象這些對象都將被序列化嗎？這有很有可能使整個數據庫數據意外的被序列化。那麼該如何解決呢？將屬性標記為不可序列化？不行，因為你不知道屬性何時該被序列化何時不該序列化。所以在這種情況下，返回一個可安全序列化，特別定制的數據傳輸對象是不錯的選擇哦。

幾乎所有的ORM框架都支持惰性加載。只有當你需要加載實體時它才會被加載。比如User類型引用Role類型。當你從數據庫獲取User時，Role屬性並沒有被填充。當你第一次讀取Role屬性時，才會從數據庫中加載Role。所以，當你返回這樣一個實體給展現層時，很容易引起副作用（從數據庫中加載）。如果序列化工具讀取實體，它將會遞歸地讀取所有屬性，這樣你的整個數據庫都將會被讀取。

在展現層中使用實體還會有更多的問題。最佳的方案就是展現層不應該引用任何包含領域層的程序集。

DTO 約定 & 驗證
ABP對數據傳輸對象提供了強大的支持。它提供了一些相關的(Conventional)類型 & 接口並對DTO命名和使用約定提供了建議。當你像這裡一樣使用DTO，ABP將會自動化一些任務使你更加輕松。

一個例子 (Example)

讓我們來看一個完整的例子。我們相要編寫一個應用服務方法根據name來搜索people並返回people列表。Person實體代碼如下:

public class Person : Entity
{
 public virtual string Name { get; set; }
 public virtual string EmailAddress { get; set; }
 public virtual string Password { get; set; }
}

首先，我們定義一個應用服務接口:

public interface IPersonAppService : IApplicationService
{
 SearchPeopleOutput SearchPeople(SearchPeopleInput input);
}

ABP建議命名input/ouput對象類似於MethodNameInput/MethodNameOutput，對於每個應用服務方法都需要將Input和Output進行分開定義。甚至你的方法只接收或者返回一個值，也最好創建相應的DTO類型。這樣，你的代碼才會更具有擴展性，你可以添加更多的屬性而不需要更改方法的簽名，這並不會破壞現有的客戶端應用。

當然，方法返回值有可能是void，之後你添加一個返回值並不會破壞現有的應用。如果你的方法不需要任何參數，那麼你不需要定義一個Input Dto。但是創建一個Input Dto可能是個更好的方案，因為該方法在將來有可能會需要一個參數。當然是否創建這取決於你。 Input和Output DTO類型定義如下：

 public class SearchPeopleInput : IInputDto
{
 [StringLength(40, MinimumLength = 1)]
 public string SearchedName { get; set; }
}

public class SearchPeopleOutput : IOutputDto
{
 public List<PersonDto> People { get; set; }
}

public class PersonDto : EntityDto
{
 public string Name { get; set; }
 public string EmailAddress { get; set; }
}

驗證：作為約定，Input DTO實現IInputDto 接口，Output DTO實現IOutputDto接口。當你聲明IInputDto參數時, 在方法執行前ABP將會自動對其進行有效性驗證。這類似於ASP.NET MVC驗證機制，但是請注意應用服務並不是一個控制器(Controller)。ABP對其進行攔截並檢查輸入。查看DTO 驗證(DTO Validation)文檔獲取更多信息。 EntityDto是一個簡單具有與實體相同的Id屬性的簡單類型。如果你的實體Id不為int型你可以使用它泛型版本。EntityDto也實現了IDto接口。你可以看到PersonDto並不包含Password屬性，因為展現層並不需要它。

跟進一步之前我們先實現IPersonAppService：

public class PersonAppService : IPersonAppService
{
 private readonly IPersonRepository _personRepository;

 public PersonAppService(IPersonRepository personRepository)
 {
 _personRepository = personRepository;
 }
 public SearchPeopleOutput SearchPeople(SearchPeopleInput input)
 {
 //獲取實體
 var peopleEntityList = _personRepository.GetAllList(person => person.Name.Contains(input.SearchedName));

 //轉換成DTO
 var peopleDtoList = peopleEntityList
  .Select(person => new PersonDto
    {
     Id = person.Id,
     Name = person.Name,
     EmailAddress = person.EmailAddress
    }).ToList();

 return new SearchPeopleOutput { People = peopleDtoList };
 }
}

我們從數據庫獲取實體，將實體轉換成DTO並返回output。注意我們沒有手動檢測Input的數據有效性。ABP會自動驗證它。ABP甚至會檢查Input是否為null，如果為null則會拋出異常。這避免了我們在每個方法中都手動檢查數據有效性。

但是你很可能不喜歡手動將Person實體轉換成PersonDto。這真的是個乏味的工作。Peson實體包含大量屬性時更是如此。

DTO和實體間的自動映射
還好這裡有些工具可以讓映射（轉換）變得十分簡單。AutoMapper就是其中之一。你可以通過nuget把它添加到你的項目中。讓我們使用AutoMapper來重寫SearchPeople方法:

public SearchPeopleOutput SearchPeople(SearchPeopleInput input)
{
 var peopleEntityList = _personRepository.GetAllList(person => person.Name.Contains(input.SearchedName));
 return new SearchPeopleOutput { People = Mapper.Map<List<PersonDto>>(peopleEntityList) };
}

這就是全部代碼。你可以在實體和DTO中添加更多的屬性，但是轉換代碼依然保持不變。在這之前你只需要做一件事：映射

Mapper.CreateMap<Person, PersonDto>();

AutoMapper創建了映射的代碼。這樣，動態映射就不會成為性能問題。真是快速又方便。AutoMapper根據Person實體創建了PersonDto,並根據命名約定來給PersonDto的屬性賦值。命名約定是可配置的並且很靈活。你也可以自定義映射和使用更多特性，查看AutoMapper的文檔獲取更多信息。

使用特性(attributes)和擴展方法來映射 (Mapping using attributes and extension methods)

ABP提供了幾種attributes和擴展方法來定義映射。使用它你需要通過nuget將Abp.AutoMapper添加到你的項目中。使用AutoMap特性(attribute)可以有兩種方式進行映射，一種是使用AutoMapFrom和AutoMapTo。另一種是使用MapTo擴展方法。定義映射的例子如下：

[AutoMap(typeof(MyClass2))] //定義映射（這樣有兩種方式進行映射）
public class MyClass1
{
 public string TestProp { get; set; }
}

public class MyClass2
{
 public string TestProp { get; set; }
}

接著你可以通過MapTo擴展方法來進行映射：

var obj1 = new MyClass1 { TestProp = "Test value" };
var obj2 = obj1.MapTo<MyClass2>(); //創建了新的MyClass2對象，並將obj1.TestProp的值賦值給新的MyClass2對象的TestProp屬性。

上面的代碼根據MyClass1創建了新的MyClass2對象。你也可以映射已存在的對象，如下所示：

var obj1 = new MyClass1 { TestProp = "Test value" };
var obj2 = new MyClass2();
obj1.MapTo(obj2); //根據obj1設置obj2的屬性

輔助接口和類型
ABP還提供了一些輔助接口，定義了常用的標准化屬性。

ILimitedResultRequest定義了MaxResultCount屬性。所以你可以在你的Input DTO上實現該接口來限制結果集數量。

IPagedResultRequest擴展了ILimitedResultRequest，它添加了SkipCount屬性。所以我們在SearchPeopleInput實現該接口用來分頁:

public class SearchPeopleInput : IInputDto, IPagedResultRequest
{
 [StringLength(40, MinimumLength = 1)]
 public string SearchedName { get; set; }

 public int MaxResultCount { get; set; }
 public int SkipCount { get; set; }
}

對於分頁請求，你可以將實現IHasTotalCount的Output DTO作為返回結果。標准化屬性幫助我們創建可復用的代碼和規范。可在Abp.Application.Services.Dto命名空間下查看其他的接口和類型。