サービスを効率的に実装するために ServiceStack リクエスト DTO 設計を最適化するにはどうすればよいですか?

ServiceStack 要求 DTO 設計

問題:

WCF から移行する場合、ServiceStack サービスに最適な要求 DTO を設計することが困難になる場合があるスタイルの RPC サービス。重複コードを減らし、複数のリクエスト シナリオを効率的に処理しようとすると、問題が発生します。

ベスト プラクティス:

メッセージ ベースの設計:

• メソッド シグネチャを RPC 呼び出しとして公開する代わりに、クエリ全体をリクエスト DTO。
• サービスは、リクエスト DTO で必要なすべての情報を取得し、サービス メソッド内のパラメータ リストの必要性を排除する必要があります。
• メッセージ ベースの設計を活用して、複数の RPC 呼び出しを 1 つに結合します。サービスの実装。

コール セマンティクスと応答によるグループ化タイプ:

• 呼び出しセマンティクス (フィルター対コンビネータ) と応答タイプ (単一項目対コレクション) に基づいてサービスを編成します。
• 次を使用して、一貫した命名スキームを維持します。サービス操作の動詞と DTO の名詞type.

リファクタリングの例:

GetBookingLimit と GetBookingLimits をリファクタリングする次の例を考えてみましょう。サービス:

元の:

[Route("/bookinglimit", "GET")]<br>パブリック クラス GetBookingLimit : IReturn<getbookinglimitresponse><br>{<pre class="brush:php;toolbar:false">public int Id { get; set; }

}
public class GetBookingLimitResponse
{

// ...

}

[Route("/bookinglimits ", "GET")]
パブリック クラスGetBookingLimits : IReturn
{

public DateTime Date { get; set; }

}
パブリック クラスGetBookingLimitsResponse
{

// ...

}

Re-因数分解:

[Route("/bookinglimits/{Id}")]<br>public class GetBookingLimit : IReturn<bookinglimit><br>{<pre class="brush:php;toolbar:false">public int Id { get; set; }

}
パブリック クラスBookingLimit
{

// ...

}

[Route("/bookinglimits/search")]
パブリック クラス FindBookingLimits : IReturn>
{

public DateTime BookedAfter { get; set; }

}

追加の考慮事項:

• から ResponseStatus プロパティを削除しますレスポンス DTO は、エラー処理のために汎用の ErrorResponse DTO に依存します。
• 個々のリクエスト DTO ではなく、サービス レベルで認証属性を適用します。
• バリデーターをServiceStack コンテナー

以上がサービスを効率的に実装するために ServiceStack リクエスト DTO 設計を最適化するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。