サービスコントラクト、プロキシ、およびサービスを別々のアセンブリに保持しない場合、サービスコントラクトとプロキシはクライアントアセンブリに存在し、サービスはサービスアセンブリに存在します。
データコントラクトを別のアセンブリに保持しない場合、データはクライアント側とサービス側のどちらに配置する必要がありますか?
データコントラクトは両方のアセンブリに存在できますか?
サービスコントラクト、プロキシ、およびサービスを別々のアセンブリに保持しない場合、サービスコントラクトとプロキシはクライアントアセンブリに存在し、サービスはサービスアセンブリに存在します。
データコントラクトを別のアセンブリに保持しない場合、データはクライアント側とサービス側のどちらに配置する必要がありますか?
データコントラクトは両方のアセンブリに存在できますか?
典型的なサービス指向のシナリオでは、サーバー側のサービス ライブラリに DataContract があります。あなたに電話をかける人は誰でも、あなたのサービスにクライアント プロキシ接続を追加することになるため、実際には DataContract を複製することになります。
したがって、「通常の」ケースでは、サーバー側に「マスター」DataContract があり、サービスにアクセスする各クライアント プロキシに個別のクラスがあります。これらのクライアントのコピーは「ネットワーク上で同一」です。たとえば、同じメッセージ形式にシリアル化されます。つまり、クライアントとサーバー間でシリアル化されたメッセージが送受信されるだけです。
サービス開発者として、サーバー側に DataContract を用意する必要があります。しかし、実際には同じことがサービス コントラクトにも当てはまります。これもサーバー側にある必要があります。そうしないと、サービス インターフェイスを世界中に公開して、サービスに接続する可能性のある人が使用することができなくなります。
サーバーごとに少なくとも次の 2 つのプロジェクトをお勧めします。
マルク
クライアント側とサーバー側の両方が参照するインターフェイスとコントラクトを含む別のアセンブリを用意することを強くお勧めします。
答えは、場合によります。
通常は別々に保管することをお勧めしますが、それらを一緒に保管することも同様に良いオプションである場合があります。
それらを分離しておくと、操作コントラクトをドラッグすることなくデータ コントラクトを参照して使用できるため、アプリケーションの構造をより柔軟に構築できます。
契約を個別にバージョン管理することもできます。
しかし、それはすべて実際のアプリケーションに依存します。