WCF：クライアントとサーバーで契約クラスをどのように維持する必要がありますか？

Question

私はサーバとクライアントを持つWCFアプリケーション（自然）で作業しています。サーバープロジェクトでは、私はコントラクト属性でクラスを定義しました。

サーバーの準備ができたら、私はサービス参照を追加し、私のためにプロキシを作成しました。私はそれを使用し、それは正常に動作しました。

コントラクトアトリビュートを持つクラス定義を含む共通のDLLを作成し、（Visual Studioによってクライアント用に生成されたクラスを使用するのではなく）サーバーとクライアントの両方で使用する場合は、 。共通のクラスを使用する場合、自動コード生成中にジェネリックコレクションが配列に変換されることを心配する必要はありません。それは愚かですか？出来ますか？誰もこれを前にしたことがありますか？これはいいですか？

デプロイメントのシナリオでは、セキュアなイントラネットにクライアントの数が限られており、サーバーに変更があるたびに既存のクライアントを更新することができます。

Answer 1

あなたがクライアントを制御している限り、そのアプローチは大丈夫です（私はそれをかなり使用します）。 Javaクライアントなどでは（明らかに）動作しません。もしあなたが非.NETクライアントをサポートする必要がないことが分かっているなら、それは強力ですが、純粋なSOA規則を破ります。特に、はい、イントラネットのシナリオは、私がこのアプローチを検討するかもしれないシナリオです。

svcutil.exeとIDEには、これを行うために既存のアセンブリからタイプを再利用するオプションがあります。

編集あなたはそれを2回コーディングせずに、クライアントで同じ検証ロジックを使用する場合は、このアプローチの別の利点は、さ - など

Answer 2

例IDataErrorInfoのためにあなたの唯一の懸念は、コレクションがになったされていない場合配列は、あなたはこれまでに行く必要はありません。 [Add Service Reference]ダイアログの[Advanced]ボタンを使用すると、このような場合に使用するタイプを指定できます。 T []の代わりにリストを使用させることができます。

Answer 3

別の共通のアセンブリで契約タイプを維持することは、本当に良い考えです。たとえば、コントラクトタイプと他のビジネスオブジェクト間の変換や、それらのタイプ間のメディエータなどの変換には、Adaptersを追加することができます。

すべてのクライアントを制御していない場合でも、共通タイプを使用すると意味があります。 .NETを使用する内部アプリケーションと、パートナー企業の信頼できるサードパーティによって消費されるサービスがあるとします。パートナーのアプリは、Java、Ruby、Pythonを使用します。この場合、パートナーは共有タイプにアクセスすることはできませんが、WSD/XSDに依存することで、クライアント側のタイプライブラリをロールバックできます。それは、あなたの社内開発者に良いタイプの共有型パッケージを提供することを妨げるものではありません。

このタイプの共有の推奨事項は、WS/SOAPではなくRESTインターフェイスを使用する場合にも適用されます。 RESTでは、WSDLは欠落していますが、サーバーとそのクライアントが交換するメッセージのタイプを記述するためにXSD（または同様のもの）が引き続き使用されます。したがって、SOAPを使用するかRESTを使用するかにかかわらず、アドバイスの変更はありません。

編集：そして、それはあなたが.NETかJavaか何か他のものを使用するかどうかにかかわらず適用されます。ワイヤーの両端をコントロールしていて、プラットフォームが同じであれば、タイプを共有する必要があります。どうして？

Answer 4

契約を保持するために別々のアセンブリを作成したら、これらのアセンブリを参照し、それらを使用してクライアントからのサービスへのチャネル（ChannelFactoryの使用）を作成することができます。これにより、サービス契約を変更するたびに、「サービス参照」を更新する必要がなくなりました。

ChannelFactory<IContract> factory = 
    new ChannelFactory<IContract>("endpointName");