ご意見ありがとうございました。wcfアーキテクチャの設計。 re：戻り値
私はWebサービスを作成しています。 このウェブサービスは、顧客および顧客の口座を、その他の関連するオブジェクトおよび属性などと一緒に受け入れます。
ウェブサービスがリクエストを受け取ると、私はそれを処理しようとします。
エラーがなければ、私は単に戻ってきます。エラーがあれば投げます。
私はこれが最善のアプローチかどうか、または応答としてboolを返すように設計を変更する必要があるか、または応答オブジェクトを作成する必要があると思います。エラーの場合は、エラーのリスト（Missing Fields、Invalid Fields、ext）。
デザインにどのような返品方法を組み込むのですか？
1）エラーがない場合はエラーを返します。エラーの場合はエラーを返します。 2）ブールの成功 3）レスポンスオブジェクト（元のリクエストオブジェクトと詳細な結果を含む）？
ありがとうございます。 スティーブン
私は「エラー」が何であるかによって異なります。エラーが検証に関連していても、通常のイベントで予期していた場合、たとえば、無効なユーザー資格がユーザー認証を提供するサービスに渡された場合、要求結果（成功、失敗など）を示すenum値が返されます。しかし、エラーが通常のイベントでは発生しない入力によるものであれば、サービス操作からのフォルトを投げることをお勧めします。フォールトを投げると、クライアントアプリケーションにエラーがあり、対処方法がわからないという入力が表示されます。特定の障害契約をWCFサービス操作に登録することができます。そのため、クライアントアプリケーションは、特定の状況下で多数の障害の1つをスローする可能性があることを知ります。クライアントアプリケーションは、これらのフォルトの例外ハンドラを提供し、スローされた場合はアクションを実行し、そうでない場合は予期せず終了します。
大雑把に言えば、私は例外的な状況下で障害を投げると言います。クライアントは、サービス操作が受け取ることを期待しない入力を提供している。クライアントが間違った情報を提供したが、サービス操作が処理するためにプログラムされている場合は、応答メッセージにステータスコードまたは情報を戻します。
私はそれがこのサービスを利用する人に依存していることを考えて、
あなたは私はあなたが何も（あるいは元の要求）を返さないと何かあれば例外をスローすることをお勧めします。このサービスを利用するだけであれば間違っている。
サービスがパブリックで使用される場合は、エラーを含む応答オブジェクトとその他の関連データを返す必要があります。
幸運
こんにちはChen Kinnrot。 お返事ありがとうございます。私はこれが内部アプリケーションではなく、wcfを使用しない外部のクライアントによって使用されることに言及することを忘れてしまった。レスポンスオブジェクトにも元のリクエストが含まれていたり、それが過度のものであったりすると、どんなメリットがありますか？ – stevenrosscampbell
私はあなたがしなければ要求を返す必要はないと思う。 結果タイプのキー（一部のサイトで結果の意味を公開します）となる単純な文字列または数値を返すことができれば、どの技術もサービスで使用できるため、これが最適です。 –
経験則として、状況によってはリクエストを正常に完了できない場合は例外をスローします。注文番号などの他の情報を返信したい場合は、戻り値を使用してください。ブール値の戻り値を介して完全な失敗を返信することは一般的には良い考えではありません。呼び出し元が無視したりチェックしたりすることはできません。
外部ソースで使用されているWCFサービスであるため、.NET固有の例外ではなく、例外をスローするだけでなく、SOAPエラーをスローする必要があります。あなたは、あなたのサービスの提供は、あなたの操作に一つ以上のFaultContract属性を追加することにより、すべての操作上のサービス契約の一部として、これらの障害を宣言する必要があります。
[FaultContract(typeof(MyFault1))]
[FaultContract(typeof(MyFault2))]
[OperationContract]
void MyOperation()
あなたは、.NET WCFで簡単にこれを行うことができますFaultExceptionをスローすることによってか、より具体的なFaultException（Exaktタイプのフォールトを指定できる汎用のバリアント）。
マーク
こんにちはPmarflee。 お返事ありがとうございます。 私の知り合いは、このWebサービスは内部的なものではなく、クライアントのためにwcfを使用しない人がいることを忘れていました。この情報に基づいて、上記で説明したモデルを使用することは可能ですか？ – stevenrosscampbell
メッセージを送信するプロトコルとしてSOAPを使用していますか？その場合、SOAP形式は、SOAPメッセージのエラーと状態情報を保持するために使用できるFault要素を定義します。 SOAPはXMLベースなので、クライアントは、使用しているプラットフォームに関係なく、障害に含まれるエラー情報を読み取ることができます。 WCF例外シールドは、サービス操作が公開するように構成されたエラーに関して、エラー情報がクライアントに伝播されることを意味します。その他のエラーは表示されず、一般的なエラーメッセージがクライアントに返されます。 – pmarflee