私は、WCF ソリューションを次のように構成するのが好きです。
Contracts
(クラス ライブラリ)
すべてのサービス、操作、障害、およびデータ コントラクトが含まれます。純粋な .NET-to-.NET シナリオでサーバーとクライアント間で共有可能
Service implementation
(クラス ライブラリ)
サービスを実装するためのコードと、これを実現するために必要なサポート/ヘルパー メソッドが含まれています。他には何もありません。
Service host(s)
(オプション - Winforms、Console App、NT Service のいずれか)
デバッグ/テスト用、または場合によっては本番用のサービス ホストが含まれます。
これにより、基本的にサーバー側のことがわかります。
クライアント側:
Client proxies
(クラス ライブラリ)
クライアント プロキシを別のクラス ライブラリにパッケージ化して、複数の実際のクライアント アプリで再利用できるようにしたいと考えています。これは、svcutil または「サービス参照の追加」を使用して、結果として生じる恐ろしい app.config を手動で微調整するか、ClientBase<T>
またはChannelFactory<T>
コンストラクトを使用して (コントラクト アセンブリを共有する場合に) クライアント プロキシを手動で実装することによって実行できます。
1-n actual clients
(どんな種類のアプリでも)
通常、クライアント プロキシ アセンブリのみを参照するか、共有されている場合はコントラクト アセンブリも参照します。これには、ASP.NET、WPF、Winforms、コンソール アプリ、その他のサービスなど、名前を付けることができます。
そのように; 私はきれいできれいなレイアウトを持っており、それを一貫して何度も使用しています。これにより、コードがよりきれいになり、保守が容易になったと本当に思います.
これは、DotNet Rocks TV での Miguel Castro のExtreme WCF スクリーン キャスト(Carl Franklin とのスクリーン キャストを強くお勧めします)に触発されました。