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

ABP提供數(shù)據(jù)過(guò)濾器(Data filters),它使用自動(dòng)化的，基于規(guī)則的過(guò)濾查詢。ABP已經(jīng)有一些預(yù)定義的過(guò)濾器,當(dāng)然也可以自行創(chuàng)建你專屬的過(guò)濾器。

注意：只針對(duì)EntityFramework:ABP數(shù)據(jù)過(guò)濾器僅實(shí)現(xiàn)在EntityFramework。還無(wú)法在其它ORM工具中使用。見(jiàn)其它ORM章節(jié)于本文末端。

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

軟刪除過(guò)濾器(Soft-delete filter )會(huì)過(guò)濾從數(shù)據(jù)庫(kù)查詢出來(lái)的實(shí)體且是自動(dòng)套用(從結(jié)果集中提取出來(lái))。如果實(shí)體需要被軟刪除,它需要實(shí)現(xiàn)ISoftDelete接口,該接口僅定義了一個(gè)IsDeleted屬性。例:

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

Person實(shí)體實(shí)際上并沒(méi)有從數(shù)據(jù)庫(kù)中被刪除,當(dāng)刪除此實(shí)體時(shí),IsDeleted屬性值會(huì)被設(shè)定為true。當(dāng)你使用IRepository.Delete方法時(shí),ABP會(huì)自動(dòng)完成這些工作(你可以手動(dòng)設(shè)定IsDeleted為true,但是Delete方法更加自然且是較建議的方式)。

當(dāng)實(shí)現(xiàn)了ISoftDelete之后,當(dāng)你已經(jīng)從數(shù)據(jù)庫(kù)中取得了People列表,已被刪除的People實(shí)體并不會(huì)被檢索到。在這里有一個(gè)示例類,該類使用了person倉(cāng)儲(chǔ)來(lái)取得所有的People實(shí)體: 

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

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

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

GetPeople方法僅取得Person實(shí)體,該實(shí)體其IsDeleted = false(非刪除狀態(tài))。所有的倉(cāng)儲(chǔ)方法以及導(dǎo)航屬性都能夠正常運(yùn)作。我們可以添加一些其它的Where條件,Join...等等。它將會(huì)自動(dòng)地添加IsDeleted=false條件到生成的SQL查詢語(yǔ)句中。

注意：何時(shí)啟用?ISoftDelete過(guò)濾器總是啟用,除非你直接禁用它。

提醒:如果你實(shí)現(xiàn)了IDeletionAudited接口(該接口繼承自ISoftDelete),刪除創(chuàng)建時(shí)間和被刪除的用戶Id，這些都會(huì)由ABP進(jìn)行自動(dòng)的處理。

2.多租接口(IMustHaveTenant)

如果你創(chuàng)建一個(gè)多租戶的應(yīng)用程序(儲(chǔ)存所有租戶的數(shù)據(jù)于單一一個(gè)數(shù)據(jù)庫(kù)中),你肯定不會(huì)希望某個(gè)租戶看到其它租戶的資料。你可以實(shí)現(xiàn)IMustHaveTenant接口于此案例中,示例如下:

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

 public virtual string Name { get; set; }
 }

 IMustHaveTenant定義了TenantId來(lái)區(qū)別不同的租戶實(shí)體。ABP使用IAbpSession來(lái)取得當(dāng)前TenantId并且自動(dòng)地替當(dāng)前租戶進(jìn)行過(guò)濾查詢的處理。

注意：何時(shí)啟用?IMustHaveTenant默認(rèn)是啟用的。如果當(dāng)前使用并沒(méi)有登入到系統(tǒng)或是當(dāng)前用戶是一個(gè)管理級(jí)使用者(管理級(jí)使用者即為一個(gè)最高權(quán)限的使用者,它可以管理所有租戶和租戶的資料),ABP會(huì)自動(dòng)地禁用IMustHaveTenant過(guò)濾器。因此,所有的租戶的數(shù)據(jù)都可以被應(yīng)用程序所檢索。注意,這與安全性無(wú)關(guān),你應(yīng)該要對(duì)敏感數(shù)據(jù)進(jìn)行驗(yàn)證授權(quán)處理。

3.多租接口(IMayHaveTenant)

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

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

 public virtual string Name { get; set; }
 }

當(dāng)為null值,則代表這是一個(gè)管理級(jí)使用者(host)所掌控的實(shí)體,若為非null值,則代表這個(gè)實(shí)體是由租戶(tenant)所掌控,而其Id值即為TenantId。ABP使用IAbpSession接口來(lái)取得當(dāng)前TenantId。IMayHaveTenant過(guò)濾器并不如IMustHaveTenant普遍常用。但是當(dāng)作為管理級(jí)使用者(host)和租戶(tenant)所需要的通用結(jié)構(gòu)使用時(shí),你或許會(huì)需要用到它。

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

禁用過(guò)濾器
可以在工作單元(unit of work)中調(diào)用DisableFilter方法來(lái)禁用某個(gè)過(guò)濾器,如下所示:

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

var people3 = _personRepository.GetAllList();

DisableFilter方法取得一或多個(gè)過(guò)濾器名稱,且類型皆為string。AbpDataFilters.SoftDelete是一個(gè)常數(shù)字符串其包含了ABP標(biāo)準(zhǔn)的軟刪除過(guò)濾器。

people2亦可取得已標(biāo)記為刪除的People實(shí)體,而people1和people3將會(huì)是唯一的非已標(biāo)記為刪除的People實(shí)體。若配合使用using語(yǔ)法,你可以禁用其控制范圍內(nèi)(Scope)的過(guò)濾器。如果你不使用 using 語(yǔ)法 ,此過(guò)濾器會(huì)被一直禁用，直到工作單元（unit of work）結(jié)束或者再度啟用它。(意思是：如果你使用"using"關(guān)鍵字聲明,過(guò)濾器是啟用狀態(tài)；當(dāng)前工作單元(unit of work)結(jié)束后，過(guò)濾器是禁止?fàn)顟B(tài)。如果不使用"using"關(guān)鍵字聲明，默認(rèn)過(guò)濾器是禁用狀態(tài)，此時(shí)可以手動(dòng)啟用過(guò)濾器。)

你可以注入IUnitOfWorkManager并且在上述示例中使用。同樣的,你可以使用CurrentUnitOfWork屬性作為一個(gè)在應(yīng)用服務(wù)中的簡(jiǎn)便方式(它是從ApplicationService類繼承而來(lái)的)。

注意：關(guān)于using語(yǔ)法:假如過(guò)濾器在你調(diào)用DisableFilter方法并配合using語(yǔ)法之前已是啟用,則過(guò)濾器會(huì)被禁用,并且會(huì)自動(dòng)地在using語(yǔ)法結(jié)束后在度啟用。但是若過(guò)濾器在using語(yǔ)法之前就已經(jīng)被禁用了,DisableFilter方法實(shí)際上并不做任何式,并且過(guò)濾器會(huì)維持禁用狀態(tài)即便是using語(yǔ)法的結(jié)束后。

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

設(shè)定過(guò)濾器參數(shù)
 過(guò)濾器可以被參數(shù)化(parametric)。IMustHaveTenant過(guò)濾器是這類過(guò)濾器的一個(gè)范本,因?yàn)楫?dāng)前租戶(tenant)的Id是在執(zhí)行時(shí)期決定的。對(duì)于這些過(guò)濾器,如果真有需要,我們可以改變過(guò)濾器的值。舉例如下:

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

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


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

然后我們就可以實(shí)現(xiàn)這個(gè)接口在我們的實(shí)體上了,示例如下:

 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; }
 }

因?yàn)锳BP使用EntityFramework.DynamicFilters這個(gè)過(guò)濾器,我們使用它的規(guī)則(rule)來(lái)定義過(guò)濾器。在我們的DbContext類中,我們重寫了OnModelCreating并且定義了過(guò)濾器如下示例所示:

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

PersonFilter過(guò)濾器在這里是一個(gè)唯一的過(guò)濾器名稱。再來(lái)就是過(guò)濾器接口的參數(shù)定義和personId過(guò)濾器參數(shù)(不一定需要,假如過(guò)濾器是屬于不可參數(shù)化(parametric)型),最后一個(gè)參數(shù)為personId的默認(rèn)值。

最后一個(gè)步驟,我們需要注冊(cè)這個(gè)過(guò)濾器到ABP工作單元(unit of work)系統(tǒng)中,設(shè)定的位置在我們模塊里的PreInitialize方法。

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

第一個(gè)參數(shù)是我們剛剛所定義的唯一名稱,第二個(gè)參數(shù)指示這個(gè)過(guò)濾器預(yù)設(shè)是啟用還是禁用。在聲明完這些可參數(shù)化(parametric)的過(guò)濾器后,我們可以在執(zhí)行期間指定它的值來(lái)操作這個(gè)過(guò)濾器。

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

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

EntityFramework.DynamicFilters的文件:若需要更多關(guān)于動(dòng)態(tài)數(shù)據(jù)過(guò)濾器的相關(guān)信息,可以見(jiàn)其在git上的文件https://github.com/jcachat/EntityFramework.DynamicFilters

我們可以為安全性創(chuàng)建一個(gè)定制化的過(guò)濾器,主/被動(dòng)實(shí)體,多租戶...諸如此類的。

其它對(duì)象關(guān)系映射工具
ABP數(shù)據(jù)過(guò)濾器僅實(shí)現(xiàn)在Entity Framework上。對(duì)于其它ORM工具則尚不可用。但是, 實(shí)際上,你可以模仿這個(gè)模式到其它使用倉(cāng)儲(chǔ)來(lái)取得數(shù)據(jù)的案例下。這此案例中, 你可以創(chuàng)建一個(gè)定制的倉(cāng)儲(chǔ)并且覆寫GetAll方法,如果有需要的話,可以一起修改其它資料檢索方法。

數(shù)據(jù)傳輸對(duì)象（DTOs）
數(shù)據(jù)傳輸對(duì)象(Data Transfer Objects)用于應(yīng)用層和展現(xiàn)層的數(shù)據(jù)傳輸。

展現(xiàn)層傳入數(shù)據(jù)傳輸對(duì)象(DTO)調(diào)用一個(gè)應(yīng)用服務(wù)方法，接著應(yīng)用服務(wù)通過(guò)領(lǐng)域?qū)ο髨?zhí)行一些特定的業(yè)務(wù)邏輯并且返回DTO給展現(xiàn)層。這樣展現(xiàn)層和領(lǐng)域?qū)颖煌耆蛛x開(kāi)了。在具有良好分層的應(yīng)用程序中，展現(xiàn)層不會(huì)直接使用領(lǐng)域?qū)ο?倉(cāng)庫(kù)，實(shí)體)。

數(shù)據(jù)傳輸對(duì)象的作用
為每個(gè)應(yīng)用服務(wù)方法創(chuàng)建DTO看起來(lái)是一項(xiàng)乏味耗時(shí)的工作。但如果你正確使用它們，這將會(huì)解救你的項(xiàng)目。為啥呢？

1.抽象領(lǐng)域?qū)?(Abstraction of domain layer)

在展現(xiàn)層中數(shù)據(jù)傳輸對(duì)象對(duì)領(lǐng)域?qū)ο筮M(jìn)行了有效的抽象。這樣你的層(layers)將被恰當(dāng)?shù)母綦x開(kāi)來(lái)。甚至當(dāng)你想要完全替換展現(xiàn)層時(shí)，你還可以繼續(xù)使用已經(jīng)存在的應(yīng)用層和領(lǐng)域?qū)?。反之，你可以重寫領(lǐng)域?qū)?，修改?shù)據(jù)庫(kù)結(jié)構(gòu)，實(shí)體和ORM框架，但并不需要對(duì)展現(xiàn)層做任何修改，只要你的應(yīng)用層沒(méi)有發(fā)生改變。

2.數(shù)據(jù)隱藏 (Data hiding)

想象一下，你有一個(gè)User實(shí)體擁有屬性Id, Name, EmailAddress和Password。如果UserAppService的GetAllUsers()方法的返回值類型為L(zhǎng)ist。這樣任何人都可以查看所有人的密碼，即使你沒(méi)有將它打印在屏幕上。這不僅僅是安全問(wèn)題，這還跟數(shù)據(jù)隱藏有關(guān)。應(yīng)用服務(wù)應(yīng)只返回展現(xiàn)層所需要的，不多不少剛剛好。

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

當(dāng)你將數(shù)據(jù)(對(duì)象)返回給展現(xiàn)層時(shí)，數(shù)據(jù)有可能會(huì)被序列化。舉個(gè)例子，在一個(gè)返回Json的MVC的Action中，你的對(duì)象需要被序列化成JSON并發(fā)送給客戶端。直接返回實(shí)體給展現(xiàn)層將有可能會(huì)出現(xiàn)麻煩。

在真實(shí)的項(xiàng)目中，實(shí)體會(huì)引用其他實(shí)體。User實(shí)體會(huì)引用Role實(shí)體。所以，當(dāng)你序列化User時(shí)，Role也將被序列化。而且Role還擁有一個(gè)List并且Permission還引用了PermissionGroup等等….你能想象這些對(duì)象都將被序列化嗎？這有很有可能使整個(gè)數(shù)據(jù)庫(kù)數(shù)據(jù)意外的被序列化。那么該如何解決呢？將屬性標(biāo)記為不可序列化？不行，因?yàn)槟悴恢缹傩院螘r(shí)該被序列化何時(shí)不該序列化。所以在這種情況下，返回一個(gè)可安全序列化，特別定制的數(shù)據(jù)傳輸對(duì)象是不錯(cuò)的選擇哦。

幾乎所有的ORM框架都支持惰性加載。只有當(dāng)你需要加載實(shí)體時(shí)它才會(huì)被加載。比如User類型引用Role類型。當(dāng)你從數(shù)據(jù)庫(kù)獲取User時(shí)，Role屬性并沒(méi)有被填充。當(dāng)你第一次讀取Role屬性時(shí)，才會(huì)從數(shù)據(jù)庫(kù)中加載Role。所以，當(dāng)你返回這樣一個(gè)實(shí)體給展現(xiàn)層時(shí)，很容易引起副作用（從數(shù)據(jù)庫(kù)中加載）。如果序列化工具讀取實(shí)體，它將會(huì)遞歸地讀取所有屬性，這樣你的整個(gè)數(shù)據(jù)庫(kù)都將會(huì)被讀取。

在展現(xiàn)層中使用實(shí)體還會(huì)有更多的問(wèn)題。最佳的方案就是展現(xiàn)層不應(yīng)該引用任何包含領(lǐng)域?qū)拥某绦蚣?/p>

 DTO 約定 & 驗(yàn)證
ABP對(duì)數(shù)據(jù)傳輸對(duì)象提供了強(qiáng)大的支持。它提供了一些相關(guān)的(Conventional)類型 & 接口并對(duì)DTO命名和使用約定提供了建議。當(dāng)你像這里一樣使用DTO，ABP將會(huì)自動(dòng)化一些任務(wù)使你更加輕松。

一個(gè)例子 (Example)

讓我們來(lái)看一個(gè)完整的例子。我們相要編寫一個(gè)應(yīng)用服務(wù)方法根據(jù)name來(lái)搜索people并返回people列表。Person實(shí)體代碼如下:

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

首先，我們定義一個(gè)應(yīng)用服務(wù)接口:

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

ABP建議命名input/ouput對(duì)象類似于MethodNameInput/MethodNameOutput，對(duì)于每個(gè)應(yīng)用服務(wù)方法都需要將Input和Output進(jìn)行分開(kāi)定義。甚至你的方法只接收或者返回一個(gè)值，也最好創(chuàng)建相應(yīng)的DTO類型。這樣，你的代碼才會(huì)更具有擴(kuò)展性，你可以添加更多的屬性而不需要更改方法的簽名，這并不會(huì)破壞現(xiàn)有的客戶端應(yīng)用。

當(dāng)然，方法返回值有可能是void，之后你添加一個(gè)返回值并不會(huì)破壞現(xiàn)有的應(yīng)用。如果你的方法不需要任何參數(shù)，那么你不需要定義一個(gè)Input Dto。但是創(chuàng)建一個(gè)Input Dto可能是個(gè)更好的方案，因?yàn)樵摲椒ㄔ趯?lái)有可能會(huì)需要一個(gè)參數(shù)。當(dāng)然是否創(chuàng)建這取決于你。 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; }
}

驗(yàn)證：作為約定，Input DTO實(shí)現(xiàn)IInputDto 接口，Output DTO實(shí)現(xiàn)IOutputDto接口。當(dāng)你聲明IInputDto參數(shù)時(shí), 在方法執(zhí)行前ABP將會(huì)自動(dòng)對(duì)其進(jìn)行有效性驗(yàn)證。這類似于ASP.NET MVC驗(yàn)證機(jī)制，但是請(qǐng)注意應(yīng)用服務(wù)并不是一個(gè)控制器(Controller)。ABP對(duì)其進(jìn)行攔截并檢查輸入。查看DTO 驗(yàn)證(DTO Validation)文檔獲取更多信息。 EntityDto是一個(gè)簡(jiǎn)單具有與實(shí)體相同的Id屬性的簡(jiǎn)單類型。如果你的實(shí)體Id不為int型你可以使用它泛型版本。EntityDto也實(shí)現(xiàn)了IDto接口。你可以看到PersonDto并不包含Password屬性，因?yàn)檎宫F(xiàn)層并不需要它。

跟進(jìn)一步之前我們先實(shí)現(xiàn)IPersonAppService：

public class PersonAppService : IPersonAppService
{
 private readonly IPersonRepository _personRepository;

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

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

 return new SearchPeopleOutput { People = peopleDtoList };
 }
}

我們從數(shù)據(jù)庫(kù)獲取實(shí)體，將實(shí)體轉(zhuǎn)換成DTO并返回output。注意我們沒(méi)有手動(dòng)檢測(cè)Input的數(shù)據(jù)有效性。ABP會(huì)自動(dòng)驗(yàn)證它。ABP甚至?xí)z查Input是否為null，如果為null則會(huì)拋出異常。這避免了我們?cè)诿總€(gè)方法中都手動(dòng)檢查數(shù)據(jù)有效性。

但是你很可能不喜歡手動(dòng)將Person實(shí)體轉(zhuǎn)換成PersonDto。這真的是個(gè)乏味的工作。Peson實(shí)體包含大量屬性時(shí)更是如此。

DTO和實(shí)體間的自動(dòng)映射
還好這里有些工具可以讓映射（轉(zhuǎn)換）變得十分簡(jiǎn)單。AutoMapper就是其中之一。你可以通過(guò)nuget把它添加到你的項(xiàng)目中。讓我們使用AutoMapper來(lái)重寫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) };
}

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

Mapper.CreateMap<Person, PersonDto>();

AutoMapper創(chuàng)建了映射的代碼。這樣，動(dòng)態(tài)映射就不會(huì)成為性能問(wèn)題。真是快速又方便。AutoMapper根據(jù)Person實(shí)體創(chuàng)建了PersonDto,并根據(jù)命名約定來(lái)給PersonDto的屬性賦值。命名約定是可配置的并且很靈活。你也可以自定義映射和使用更多特性，查看AutoMapper的文檔獲取更多信息。

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

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

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

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

接著你可以通過(guò)MapTo擴(kuò)展方法來(lái)進(jìn)行映射：

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

上面的代碼根據(jù)MyClass1創(chuàng)建了新的MyClass2對(duì)象。你也可以映射已存在的對(duì)象，如下所示：

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

 輔助接口和類型
ABP還提供了一些輔助接口，定義了常用的標(biāo)準(zhǔn)化屬性。

ILimitedResultRequest定義了MaxResultCount屬性。所以你可以在你的Input DTO上實(shí)現(xiàn)該接口來(lái)限制結(jié)果集數(shù)量。

IPagedResultRequest擴(kuò)展了ILimitedResultRequest，它添加了SkipCount屬性。所以我們?cè)赟earchPeopleInput實(shí)現(xiàn)該接口用來(lái)分頁(yè):

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

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

對(duì)于分頁(yè)請(qǐng)求，你可以將實(shí)現(xiàn)IHasTotalCount的Output DTO作為返回結(jié)果。標(biāo)準(zhǔn)化屬性幫助我們創(chuàng)建可復(fù)用的代碼和規(guī)范?？稍贏bp.Application.Services.Dto命名空間下查看其他的接口和類型。