WCF の複数のデータ コントラクト、または複数のデータ モデル クラスを表す複数のサービス コントラクト?

Question

私の WPF アプリケーション データ モデルには、WCF セルフホスト サービスを介してバックエンド DB と対話するためのデータを表す複数のクラスがあります。

これらの複数の WPF データ モデル クラスを表すために、WCF サービスに複数のデータ コントラクト、または複数のサービス コンタクトまたはエンドポイントが必要ですか?この場合、WCF を構築する正しい (または唯一の) 方法は何ですか?

Answer 1

という設計推奨事項があります。 界面分離原理 これは基本的に、iDesign WCF コーディング標準にも記載されていることを示しています。インターフェース (= サービス契約) を大きくしすぎたり、扱いにくくしたりしないでください。

このことを考慮：あなたは何百ものメソッドを持つ巨大なサービス契約を結んでいますが、一部のサードパーティは機能のサブセット (おそらくそれらのサービス メソッドのうち 2 つまたは 3 つだけ) を実装したいと考えています。単一の巨大なサービス契約がある場合、対象となる 3 ～ 4 つのサービス メソッドを実装する必要があり、その他のサービス メソッドはすべてダミーをスタブする必要があります。何かのようなもの throw new NotImplementedException(); か何か。一般的に、これは良い考えではありません。

したがって、基本原則は次のようになります。他の誰かがサブセットを実装する必要がある場合、必要なメソッドがすべて含まれ、他には何も含まれていない単一のサービス コントラクトが見つかる可能性が高いように、サービス コントラクトをグループ化してください。サービス契約をトピックごとにグループ化してください。住所を検索する方法が 6 つある場合は、それらを別のサービス契約に含めてください。新しいアドレスを挿入したり、既存のアドレスを更新したり削除したりする方法が他に 7 つある場合は、おそらく別のサービス契約にする必要があります (アドレスを検索するだけで何も変更しない人がいると考えられるためです)。

したがって、何が良いか悪いという明確なルールはないと思います。サービスを「論理的に接続された」メソッドのグループにグループ化するようにしてください。確かに、それは簡単なことではありません。しかし、他の人があなたのサービスをどのように利用しているかを考えることは、努力する価値があります。

また、小規模なサービス契約をいくつか結んでいる場合は、何かを変更する必要がある場合も非常に簡単です。サービス契約に重大な変更を導入する必要がある場合、影響を受けるのは、その特定のサービス契約の、いくつかのメソッドを使用する (できれば少数の) ユーザーのみです。200 もの膨大なメソッド サービス契約を常に変更しなければならない場合、常に全員に影響を与えることになります。それは良いことではないかもしれません。

Answer 2

WCF用語でデータコントラクトは、サービスコントラクトの操作に使用されるクラスです。それは通常、データコントラクトと呼ばれています.NET 3.5 SP1は、 DataContractSerializer）はもはや必須ではありません。だから、すべて単一のエンドポイントにさらさ複数のデータコントラクトを扱う複数の操作を持つ単一のサービス契約を結んでいる可能性があります。