ServiceStack のメッセージベースのアプローチはリクエスト DTO 設計をどのように改善できるでしょうか?

ServiceStack Request DTO 設計

WCF や WebAPI などの Web サービス フレームワークでは、API 呼び出しを、特定のシグネチャを備えた通常の C# メソッド呼び出しとして考えることが推奨されています。それぞれのリクエスト。対照的に、ServiceStack は、クエリ全体がリクエスト メッセージにキャプチャされるメッセージ ベースのアプローチを採用しています。これには次のような利点があります。

• 複数の RPC 呼び出しを 1 つのメッセージベースのサービスに圧縮
• 呼び出しのセマンティクスと応答タイプに基づいてサービスをグループ化

GetBooking の制限の再ファクタリングサービス

これらの概念を GetBookingLimit サービスと GetBookingLimits サービスに適用して、次の点を考慮してください。

• サービス オペレーションとタイプを区別します。 リクエスト DTO (オペレーション) を保持します。 ) 応答 DTO とは別個 (データ
• 汎用応答を返す: エラーは汎用 ErrorResponse DTO 経由で返されるようになるため、応答 DTO から ResponseStatus プロパティを削除します。
• 一貫した命名規則を維持する: 一意のキー クエリには 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 Validation を使用することで処理できます。
• 自動検証のために、container.RegisterValidators(typeof(CreateBookingValidator).Assembly) でバリデータを登録します。侵入的なコードを追加することなく、
• 作成と更新の両方に単一の StoreBooking リクエスト DTO を使用することを検討してください。

これらの原則に従うことで、ServiceStack のメッセージベースのアプローチを使用してリクエスト DTO を効果的に設計および実装できます。コードのドライさと明瞭さを促進します。

以上がServiceStack のメッセージベースのアプローチはリクエスト DTO 設計をどのように改善できるでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。