サーバーとクライアントを使用して（当然のことながら）WCFアプリケーションに取り組んでいます。サーバー プロジェクトでは、コントラクト属性を持つクラスを定義しました。
サーバーの準備ができたら、サービス参照を追加し、プロキシを作成しました。私はそれを使用しましたが、うまくいきました。
私が尋ねたい質問は、コントラクト属性を持つクラス定義を含む共通の DLL を作成し、それをサーバーとクライアントの両方に使用しても問題ないかということです (Visual Studio によってクライアント用に生成されたクラスを使用する代わりに)。共通クラスを使用する場合、自動コード生成中にジェネリック コレクションが配列に変換されることを心配する必要はありません。ばかげていますか？出来ますか？誰もこれをやったことがありますか？これを行ってもよろしいですか？
展開シナリオは、安全なイントラネット内に限られた (少数の) クライアントが存在し、サーバーに変更があった場合はいつでも既存のクライアントを更新できるようなものです。
個別の共通アセンブリでコントラクト型を維持することは、非常に良い考えです。これにより、アダプタを追加して、たとえば、コントラクト タイプと他のビジネス オブジェクトの間で変換したり、それらのタイプの間でメディエータなどを変換したりできます。
すべてのクライアントを制御しない場合でも、共通の型を使用することは理にかなっています。.NET を使用する社内アプリと、パートナー企業の信頼できるサード パーティによって利用されるサービスがあるとします。パートナー アプリは、Java、Ruby、または Python を使用します。この場合、パートナーは共有型にアクセスできませんが、WSD/XSD に依存して、独自のクライアント側の型ライブラリを作成できます。だからと言って、共有型の素敵なパッケージを社内開発者に提供することを妨げるべきではありません。
タイプを共有するというこの推奨事項は、WS/SOAP ではなく REST インターフェースを使用する場合にも当てはまります。REST には WSDL がありませんが、サーバーとそのクライアントが交換するメッセージの種類を記述するために XSD (または同様のもの) が引き続き使用されます。したがって、SOAP を使用するか REST を使用するかに関係なく、アドバイスに変更はありません。
編集:そして、.NET、Java、またはその他のものを使用するかどうかに関係なく適用されます。ワイヤの両端を制御し、プラットフォームが同じである場合は、はい、型を共有する必要があります。なぜあなたはしないのですか？
コレクションを配列に変換しないことが唯一の懸念事項である場合は、ここまでする必要はありません。[サービス参照の追加] ダイアログの [詳細] ボタンを使用すると、このような場合に使用するタイプを指定できます。T[] の代わりに List を使用できます。
クライアントを制御する限り、そのアプローチは問題ありません (私はかなり使用します) 。Java クライアントなどでは (明らかに) 動作しません。.NET 以外のクライアントをサポートする必要がないことがわかっている場合は、強力ですが、純粋な SOA ルールに違反します。特に、イントラネットのシナリオでは、このアプローチを検討する可能性があります。
svcutil.exe と IDE の両方に、既存のアセンブリの型を再利用してこれを正確に行うためのオプションがあります。
このアプローチのもう 1 つの利点は、クライアントで同じ検証ロジックを 2 回コーディングせずに使用する場合ですIDataErrorInfo。