數據傳輸對象（DTOs）
數據傳輸對象(Data Transfer Objects)用於應用層和展現層的數據傳輸。
展現層傳入數據傳輸對象(DTO)調用一個應用服務方法，接著應用服務通過領域對象執行一些特定的業務邏輯並且返回DTO給展現層。這樣展現層和領域層被完全分離開了。在具有良好分層的應用程序中，展現層不會直接使用領域對象(倉庫，實體)。
1.數據傳輸對象的作用：
為每個應用服務方法創建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。所以，當你返回這樣一個實體給展現層時，很容易引起副作用（從數據庫中加載）。如果序列化工具讀取實體，它將會遞歸地讀取所有屬性，這樣你的整個數據庫都將會被讀取。
在展現層中使用實體還會有更多的問題。最佳的方案就是展現層不應該引用任何包含領域層的程序集。
2.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實體包含大量屬性時更是如此。
3.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的文檔獲取更多信息。
4.使用特性(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的屬性
5.輔助接口和類型
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命名空間下查看其他的接口和類型。
應用服務
應用服務用於將領域(業務)邏輯暴露給展現層。展現層通過傳入DTO(數據傳輸對象)參數來調用應用服務，而應用服務通過領域對象來執行相應的業務邏輯並且將DTO返回給展現層。因此，展現層和領域層將被完全隔離開來。在一個理想的層級項目中，展現層應該從不直接訪問領域對象。
1.IApplicationService接口
在ABP中，一個應用服務需要實現IApplicationService接口。最好的實踐是針對每個應用服務都創建相應的接口。所以，我們首先定義一個應用服務接口，如下所示：
public interface IPersonAppService : IApplicationService
{
void CreatePerson(CreatePersonInput input);
}
IPersonAppService只有一個方法，它將被展現層調用來創建一個新的Person。CreatePersonInput是一個DTO對象，如下所示：
public class CreatePersonInput : IInputDto
{
[Required]
public string Name { get; set; }
public string EmailAddress { get; set; }
}
接著，我們實現IPersonAppService接口:
public class PersonAppService : IPersonAppService
{
private readonly IRepository<Person> _personRepository;
public PersonAppService(IRepository<Person> personRepository)
{
_personRepository = personRepository;
}
public void CreatePerson(CreatePersonInput input)
{
var person = _personRepository.FirstOrDefault(p => p.EmailAddress == input.EmailAddress);
if (person != null)
{
throw new UserFriendlyException("There is already a person with given email address");
}
person = new Person { Name = input.Name, EmailAddress = input.EmailAddress };
_personRepository.Insert(person);
}
}
以下是幾個重要提示：
2.應用服務類型
應用服務(Application Services)需要實現IApplicationService接口。當然，你可以選擇將你的應用服務(Application Services)繼承自ApplicationService基類，這樣你的應用服務也就自然而然的實現IApplicationService接口了。ApplicationService基類提供了方便的日志記錄和本地化功能。在此建議你針對你的應用程序創建一個應用服務基類繼承自ApplicationService類型。這樣你就可以添加一些公共的功能來提供給你的所有應用服務使用。一個應用服務示例如下所示：
public class TaskAppService : ApplicationService, ITaskAppService
{
public TaskAppService()
{
LocalizationSourceName = "SimpleTaskSystem";
}
public void CreateTask(CreateTaskInput input)
{
//記錄日志，Logger定義在ApplicationService中
Logger.Info("Creating a new task with description: " + input.Description);
//獲取本地化文本(L是LocalizationHelper.GetString(...)的簡便版本, 定義在 ApplicationService類型)
var text = L("SampleLocalizableTextKey");
//TODO: Add new task to database...
}
}
本例中我們在構造函數中定義了LocalizationSourceName，但你可以在基類中定義它，這樣你就不需要在每個具體的應用服務中定義它。查看日志記錄(logging)和本地化(localization)文檔可以獲取更多的相關信息。
