ServiceStack 基於訊息的方法如何改進請求 DTO 設計？

ServiceStack 請求DTO 設計

WCF 和WebAPI 等Web 服務框架鼓勵將API 呼叫視為普通的C# 呼叫，並具有特定的簽名每個請求。相較之下，ServiceStack 採用基於訊息的方法，其中整個查詢都在請求訊息中捕獲。這具有以下優點：

• 將多個RPC 呼叫壓縮為單一基於訊息的服務
• 根據呼叫語義和回應類型將服務分組

重建GetBooking 限制服務

應用這些對於您的GetBookingLimit 和 GetBookingLimits 服務的概念，請考慮以下事項：

• 區分服務操作與類型： 將要求 DTO（操作）與回應 DTO（資料類型）分開。
• 傳回通用回應：刪除 ResponseStatus 屬性來自回應 DTO，因為錯誤現在將透過通用 ErrorResponse DTO 傳回。
• 保持一致的命名法： 保留 Get 用於唯一鍵查詢，並使用 Find 或 Search 來傳回多個結果的查詢。
• 以自描述合約為目標：使用描述性屬性名稱使請求 DTO變得容易

重構程式碼：

[Route("/bookinglimits/{Id}")]
public class GetBookingLimit : IReturn<BookingLimit>
{
    public int Id { get; set; }
}

[Route("/bookinglimits/search")]
public class FindBookingLimits : IReturn<List<BookingLimit>>
{
    public DateTime BookedAfter { get; set; }
}

[Authenticate]
public class BookingLimitService : AppServiceBase 
{ 
    public BookingLimit Get(GetBookingLimit request) 
    { 
        return new BookingLimit {...};
    }

    public List<BookingLimit> Get(FindBookingLimits request) 
    { 
        return new List<BookingLimit> {...};
    }
}

錯誤處理與驗證

• 錯誤處理與驗證
• 可以透過拋出C# 例外狀況或使用Fluent 來處理錯誤驗證。

使用 container.RegisterValidators(typeof(CreateBookingValidator).Assembly) 註冊驗證器以進行自動驗證，而無需向服務添加侵入性代碼。

考慮使用單一StoreBooking 請求DTO 進行建立和更新.透過遵循這些原則，您可以使用以下方法有效地設計和實作請求DTO： ServiceStack基於訊息的方法，促進代碼乾燥和清晰。

以上是ServiceStack 基於訊息的方法如何改進請求 DTO 設計？的詳細內容。更多資訊請關注PHP中文網其他相關文章！