個々の WCF サービス ソリューション レベルで DataContract を定義するのではなく、エンタープライズ レベルのアセンブリで DataContract を定義してから WCF サービス プロジェクトで参照することは良い方法ですか? 私が見たすべての WCF の例は、そのトピックを避けており、サービス ソリューションで DataContracts のみを定義しています。私が話をした一部のプログラマーは、DataContracts を、サービス ローカル コントラクトではなく、エンタープライズ レベルの正規データ モデルの別のフレーバーと見なしたいと考えています。私はまだその観点に賛成または反対する議論を見つけていません.
この質問に対する正しい答えを選ぶのは難しいかもしれませんが、試してみます。少なくとも、トピックの理解に役立つと思われるものには賛成票を投じます。
DataContracts（およびサービスコントラクト）をアセンブリに入れて、サービスやクライアントなどと共有するというアイデアは本当に好きですが、すべてを1つのモノリシックアセンブリにまとめる正当な理由はありません。
それらの使用方法に基づいて、それらをアセンブリに入れる方が理にかなっています。複数のサービスやクライアント間で共有されるそれらのグループがある場合、それは1つのアセンブリなどです。
これを行うと、メタデータを公開する必要がなくなり、サーバー側とクライアント側の両方でシリアル化イベントにフックするなどの気の利いた作業が可能になると思います。
IDesign.net の人々は、プロジェクト間でコントラクト アセンブリを共有することを推奨しています。個人的には、すべてのプロキシを作成するよりもこれをお勧めします。そうしないと説得力のある理由は本当にありません。
懸念事項がここで分離されていることを確認することが重要です。提案されたアセンブリには、より頻繁に DLL を再配布することに悩まされないように、実装ではなく型のみを含める必要があります。
また、1 つのモノリシック アセンブリではなく、一緒にバージョン化するコントラクトをアセンブリにグループ化することをお勧めします。これにより、エンタープライズレベルの契約に非常に小さな変更を加えるときのオーバーヘッドが削減されます。
コンピュータサイエンスのほとんどのものと同様に、答えは-それは異なります:)
データ契約クラスは、1つ、2つのサービス、または企業全体の範囲内で関連性がありますか？彼らは変わる可能性がありますか？この種の質問について考えてください。
それらをグローバルアセンブリの一部にしたい場合で、.NET 3.5 Sp1を使用している場合は、データクラスにDataContract/DataMember属性が必要なくなったことを確認してください。System.ServiceModelに依存したくない場合（ほとんどの場合は依存しない場合）に役立つことがあります。