メソッドごとに1つのリクエスト/レスポンスオブジェクトを作成するか、サービスごとに1つのリクエスト/レスポンスオブジェクトを作成する必要がありますか？WCFデザイン - 1つの要求および応答オブジェクトまたは複数
ほとんどすべてのメソッドで同じ入力を使用するため、私のサービス要求オブジェクトには5つの異なるものしかありません。
応答オブジェクトには、辞書、ブール、IDを表すint、およびその名前の文字列値のみがあります。私は、1つのオブジェクトを使用するのではなく、すべてが同じオブジェクトを内部に持つ別々のオブジェクトの集合を作成する際のポイントを確かめていません。
ベストプラクティスとは何でしょうか？
このメソッドが提供し返す要求と応答の情報のみを含むメソッドごとにアドバイスします。その理由は、wsdlからプロキシコードを生成するときに、そのメソッドの期待が何であるかをクライアントに呼び出すことがより明確になるからです。
はIMOワンサイズ全ての答えはありません - あなたは、ワイヤの両端にわたって「コントロール」を持っている場合、それは
を依存（すなわち、独自の.NETクライアントは、WCFの唯一の消費者でありますサービス）の場合、共有タイプは理にかなっています（つまり、クライアントとサーバーで同じエンティティアセンブリを再利用する）。これを行うと、プロジェクト内のすべてのサービスで共通のエンティティを共有することで、結果コード、ページネーション情報、追加のカスタムコンテキスト情報などのホイールを再構築する時間を節約できます。また、生成されたサービス参照を使用することもできますし、クライアント内のClientBase <>を共有ServiceContractインターフェイスに対して直接使用することもできます。この場合、データの正確なシリアライズ/デシリアライズが行われている限り、データはワイヤ全体でどのように見えるかは気にしません。
ただし、WCFサーバーの他の非.NETコンシューマーが存在する場合は、その他の考慮事項があります。
DataContractSerializerは、各メソッド（通常はMethodおよびMethodResponse）に対して、メソッドシグネチャが両方（パラメータ変数名を含む）で公開された要求および応答スキーマを作成します。要求と応答の共通のエンティティが再利用可能なエンティティに「ロール」されるかどうか、または新しいエンティティが毎回作成されるかどうかについて、クライアントのWSDLマッピングテクノロジに依存します。
DCSでは、無関係なフィールド/パラメータを単一のクラスにラップすることはありません。メッセージの署名は
public DoSomethingResult DoSomething(int parameter1, SomeEntity parameter2, string parameter3);
MessageContractsとすることもできます。これにより、ワイヤを介してデータがどのように見えるかについて、より多くのことを考えるように強制され、要求と応答はラッパーエンティティに含まれます。 IMO MessageContractsは、EAIシナリオ（BizTalkコンシューマがある場合など）でうまく機能し、複数のサービス呼び出しで再利用できることを示唆するような共通の応答メッセージとして機能します。
HTH
私はNick Ryanの答えに同意します。しばらく前に書いたブログをチェックしてください。http://www.link-intersystems.com/blog/2012/01/12/pros-and-cons-of-service-layer-designs/