WCFサービスのメソッドで出力パラメータを使用することは悪い習慣ですか？

Question

私は通常の "outパラメータが混乱していて、メソッドが複数のことを行っていることを示しています"という理由を探しています.WCFサービスの出力パラメータについて特に悪い点があります。私が今働いているところでは、WCFサービスでそれらに対してルールがあり、私はその理由を理解しようとしています！

Answer 1

個人的には、特定の場所（TryParse（）というメソッドなど）でパラメータを使用します。だから、私はあなたが特定の限られた場所でしかそれを使用しないことについてあなたが話した偏見の一部を持っています。さらに、.Netアプリケーションがこれをもう一方の側で消費すると仮定することはできません。 WCFは（他の通信タイプの中でも）SOAPまたはREST Webサービスとしてインターフェイス消耗品を提供するため、WCFがnon.Netコンシューマとの互換性のためにパラメータをサポートすることを保証できません。

さらに、WCFサービスはコンシューマーにAPIを提供しており、APIは、サーバーメソッドがどのようにコード化されたかに関する限られた知識で消費すべきインターフェイスを提供する必要があります。 （WCFサーバーを書いている人が相手を書いている人と同じであるとは思わないでください）。 API上でoutパラメーターを使用しようとすると、コードの匂いのように思えます。恐らく、消費者に別の値を返すためにoutパラメータを使用するでしょう。メッセージオブジェクトを代わりに使用することを検討してください。メッセージオブジェクトは、具体的には、WCFサーバーからコンシューマに送信する必要があるすべてのデータで構成されます。あなたはそれが成功した場合、ユーザーの作成が正常に発生を示すブール値とユーザーを含むユーザーオブジェクトを返すつもり

bool TryCreateUser(string name, string email, out User user){} 

：たとえば、あなたがTryCreateUserと呼ばれるWCFサーバで公開されたメソッドを持っているとしましょう。バック消費者にこのメッセージオブジェクト

class UserCreationMessage { 
    bool IsSuccessful; 
    User user; 
} 

戻り、そしてあなたはまだ、複数の戻り値を取得することができます。私は、新しいクラス、UserCreationMessageを作成します。ただし、APIのエンドユーザーにとってよりわかりやすい一貫したオブジェクトが返されるようになりました。

最後に、私は、このサービスのコンシューマを作成するプログラマが簡単にAPIを見て消費できなければならないため、WCFサーバーなどのAPIにoutパラメータを持つことは悪い習慣であると考えていますそれは外のパラムが存在するというフープを飛び越えずに。このためのより良い設計が存在するので、それを使用してください。 APIは、特にエンドコンシューマに公開されたインタフェースで、より高いコーディング標準を必要とします。

Answer 2

サービス参照を追加するときに生成されるプロキシクラスによってパラメータが処理される理由の1つは余分なオーバーヘッドです。

this postによれば、元のoutが消費されても最後になっても最初に紛らわしくなり、誰かがこれを理解するまでに時間がかかるかもしれない複雑なエラーにつながる可能性があります。

個人的意見：WCF操作（メソッド）は何かをして何かを返す必要があります。それはたくさんのことをするかもしれませんが、その結果である1つのものだけを返します。余計なものが必要な場合は、複雑なタイプを必要とするものすべてをそのタイプのデータフィールドとして返します。