ABP DTOs (Data Transfer Objects)

DTO

在 Domain 及 Application 層是使用 Entity,
而 Application 層 Presentation 層溝通則會使用 DTO ，
跟 presentation 層溝通則會使用 DTO ，
所以 DTO 通常有以下幾項特性，

1. 不應該包含 商業邏輯的驗證
2. 要可以被序列化
3. 通常是沒有參數的建構子
4. 所有的屬性都是 Public 可存取的
5. 不應該繼承自 Entity 或是有 Entity 類型的屬性

驗證

DTO 的驗證可以透過 data annotation attributes ，
或是 實作 IValidatableObject 來做進階的驗證

與 Entity 的轉換則會透過 AutoMapper 來幫忙。
當將 input DTO 透過 Mapper 轉成 Entity 時要注意以下幾點，

1. Entity 是否有需要參數的 Constructor ，導致 Mapper 失敗
2. Entity 是否有私有的屬性需要透過公用的 Method 呼叫，才能適用 Entity 的商業羅輯，直接設定屬性可能會違反商業羅輯
3. 要小心的驗證跟處理使用者輸入的物件

input DTO

使用 input DTO 時，請注意以下幾點

1. 不要新增沒有使用到的屬性
2. 不要重用 DTO 物件(繼承也是一樣)

在許多的情境中，程式碼的重覆 會比 程式碼耦合更好

例如，都用 EventDto 是不好的

public interface IEventAppService : IApplicationService
{
	Task<EventDto> GetAsync(Guid id);
	Task CreateAsync(EventDto input);
	Task UpdateEventTimeAsync(EventDto input);
}

以下每個 Method 的參數都使用不同的 Dto

public interface IEventAppService : IApplicationService
{
	Task<EventDto> GetAsync(Guid id);
	Task CreateAsync(EventCreationDto input);
	Task UpdateEventTimeAsync(EventTimeUpdateDto input);
}

output DTO

output DTO 跟 input DTO 不同，重用的問題不適用在 output DTO
通常 output DTO 會傳出比 client 端需要的更多屬性，
這個的好處是當 client 需要額外屬性時，不需要改 output DTO

public interface IEventAppService : IApplicationService
{
	Task<EventDto> CreateAsync(CreateEventDto input);
	Task<EventDto> GetAsync(Guid id);
	Task<List<EventDto>> GetListAsync(PagedResultRequestDto
	input);
	Task<EventDto> AddSessionAsync(Guid id,
	AddSessionDto input);
}

• 註: 當有效能考量時，可依不同的情境用不同的 output DTO

參考資源

ABP Data Transfer Objects