0

私はいくつかのサービスを設計していますが、私が使用している規則についてフィードバックを得たいと思っています。

すべての操作について、次の利点があるため、常に「コンテキスト」オブジェクトと「結果」オブジェクトを定義します。

  • 拡張性: インターフェイスを変更せずに、コンテキストにパラメーターを追加したり、結果にオブジェクトを追加したりできます
  • コンパクトさ: 多くのパラメーターが必要な場合でも、定義内のオブジェクトは 1 つだけです。

例:

[OperationContract]    
DoSomethingResult DoSomething(DoSomethingContext context)

とにかく、次の理由により、これが最善の方法であるかどうかはわかりません。

  • オーバーヘッド: 私は常に応答プロパティをオブジェクトにラップします。Result オブジェクトにプロパティがない場合があります
  • バージョン管理: WCF にはコントラクトのバージョン管理が組み込まれているため、別のバージョンを使用して違いを通知する方がよい場合があります。

実際、私は通常の方法でも同じテクニックを使用しているので、フィードバック、アドバイス、批評家などを得ることが重要です。

ありがとうございました

4

2 に答える 2

3

契約書の書き方は完全に合法だと思います。私はこの種のコントラクトを使用して多くのプロジェクトに取り組んできましたが、開発中は非常に簡単で (オブジェクトにプロパティを追加するだけで完了です)、すべてに適用される簡単で明確なパターンです。サービスを提供し、すべての操作に対して単一の検証方法などを可能にします。

あなたの懸念に応えて:

  • 空のオブジェクトを作成するオーバーヘッドはまったく重要ではないと思います。問題にならない限り、これについて心配する必要はありません。
  • Result オブジェクトにプロパティがない場合 (つまり、何も返さない場合) は、単純に void を返します。空のオブジェクトを返しても何も得られません。
  • コントラクトをバージョン管理する際に、これらのオブジェクトをバージョン管理できます (おそらくそうすべきです)。あなたが行っていることは、オブジェクトのバージョン管理を妨げるものではありません。

DoSomethingResult_v1以前見たように、オブジェクトのバージョン管理はオブジェクトを に変更することを意味しないことに注意してくださいDoSomethingResult_v2。名前空間でバージョン管理する必要があります。それは物事をより明確できれいにします。操作コントラクトとデータ メンバー属性の両方で、XML 名前空間にバージョンを配置するだけです。

于 2011-02-13T07:50:45.453 に答える
2

ここでパフォーマンスの問題はないと思います。また、コード所有者の観点からは、コードは扱いやすいように見えます。

私の大きな懸念は、消費者の観点からは、あなたのサービスがどのように機能するかがまったく明確ではないということです. 別のドキュメントまたはエラー メッセージに依存する必要があります。

必要なパラメーターが宣言されていれば、コードに不慣れな人 (つまり、WSDL をダウンロードしたばかり) がサービスを利用するのははるかに簡単になります。また、すぐに使用できる十分な検証も得られます。

説明する:

[OperationContract]     
DoSomethingResult DoSomething(DoSomethingContext context) 

[OperationContract]   
[FaultContract(typeof(CustomerNotFoundFault))]   
Customer GetCustomer(UInt32 customerId) 

この点は、主に API の設計に関連しています。これがあまり関係ないのは、あなたがサービスの作成者であると同時に消費者でもあるということです。

バージョン管理に名前空間を使用するという Kirk Broadhurst の提案を全面的に支持します。私はそれを使用していますが、うまく機能します。

編集:2回目の読書で、私はあなたの投稿を読み間違えたと思います。ここでは、パラメーター オブジェクトと戻り値オブジェクトは、すべてのサービスで使用する汎用オブジェクトであると想定していました。それらが実際に各サービスに固有のものである場合、それは私が何度も成功裏に使用してきた優れたアプローチです。あなたはそれでうまくいくでしょう。

于 2011-02-13T13:01:09.430 に答える