0

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

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

4

2 に答える 2

2

インターフェイス分離の原則と呼ばれる設計上の推奨事項があります。これは、基本的に iDesign WCF コーディング標準でも述べられていることを述べています。インターフェイス (= サービス コントラクト) を大きくしすぎたり、扱いにくすぎたりしないでください。

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

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

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

また、いくつかの小規模なサービス契約を結んでいる場合は、何かを変更する必要が生じた場合もはるかに簡単です。サービス コントラクトに重大な変更を導入する必要がある場合、影響を受けるのは、その特定のサービス コントラクトのいくつかのメソッドを持つ (できれば少数の) ユーザーだけです。巨大な 200 メソッドのサービス契約を常に変更しなければならない場合、常にすべての人に影響を与えることになります - それは良いことではないかもしれません!

于 2009-12-12T22:24:04.597 に答える
1

WCF の用語では、データ コントラクトはサービス コントラクト操作で使用されるクラスです。データ コントラクトと呼ばれるのは、認識して正常にシリアル化するために、通常はDataContractAttributeで注釈が付けられているためです (ただし、.NET 3.5 SP1 以降、 DataContractSerializerは POCO オブジェクトで動作し、この属性は不要になりました)。したがって、単一のエンドポイントですべて公開されている複数のデータ コントラクトを処理する複数の操作を含む単一のサービス コントラクトを持つことができます。

于 2009-12-12T17:34:28.277 に答える