11

私は通常の「outパラメーターが混乱していて、メソッドが複数のことを実行していることを示している」スタイルの引数を超えた理由と、WCFサービスの出力パラメーターについて特に悪いことについて探しています。私が今働いている場所では、WCFサービスでそれらに対してルールがあり、その理由を解明しようとしています。

4

2 に答える 2

29

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

それを超えて、WCFサービスはコンシューマーにAPIを提供し、APIは、サーバーメソッドがどのようにコーディングされたかについての限られた知識で消費される必要があるインターフェイスを提供する必要があります。（WCFサーバーを作成している人が、もう一方の端でクライアントを作成している人と同じであると思い込まないでください）。APIでoutパラメータを使用しようとすると、コードの臭いのように見えます。おそらく、out paramを使用して、別の値をコンシューマーに返します。代わりに、メッセージオブジェクトを使用することを検討してください。メッセージオブジェクトは、WCFサーバーからそのコンシューマーに送信する必要のあるすべてのデータで具体的に構成されます。たとえば、TryCreateUserという名前のメソッドがWCFサーバーで公開されているとします。

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

ここで、ユーザーの作成が正常に行われた場所を示すブール値と、成功した場合はユーザーを含むUserオブジェクトを返します。新しいクラスUserCreationMessageを作成します。

class UserCreationMessage {
    bool IsSuccessful;
    User user;
}

このメッセージオブジェクトをコンシューマーに返します。それでも、複数の戻り値を取得できます。ただし、APIのエンドユーザーにとってよりわかりやすいコヒーレントオブジェクトが返されるようになりました。

結局、このサービスのコンシューマーを作成するプログラマーは、APIを簡単に確認して、ジャンプせずに使用できる必要があるため、WCFサーバーなどのAPIにoutパラメーターを含めることはお勧めできません。 outパラメータが存在するフープ。このためのより良い設計が存在するので、それを使用してください。APIは、特にエンドコンシューマーに公開されるインターフェイスで、より高いコーディング標準を必要とします。

于 2011-01-19T10:01:04.700 に答える
7

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

別の理由：この投稿によると、元のoutパラメーターを消費したときに最後であっても、それが最初になり、混乱を招き、誰かがこれを理解するまで解決に時間がかかる可能性のある複雑なエラーにつながる可能性があります。

個人的な意見：WCF操作（メソッド）は何かを実行して何かを返す必要があります。多くのことを行う可能性がありますが、結果として返されるのは1つだけです。余分なものが必要な場合は、必要なものすべてをその型のデータフィールドとして含む複合型を返すようにしてください。

于 2011-01-19T10:06:30.003 に答える