まず、アーキテクチャに関する限り、このソリューション構造は適切か教えてください。私はXXXXを持っています。センターのビジネス プロジェクト。XXXX。契約プロジェクトにはそれの参照があります。XXXX。サービス プロジェクトには、契約およびビジネス プロジェクトの参照があります。
今、私は自分のサービスを柔軟な環境でホストしたいと考えています。そのため、カスタム ホスティング ロジックを Service > Host フォルダーに配置します。このプロジェクトにはカスタム インスタンスを提供する機能もあり、パラメトリック コンストラクターを使用して My サービス クラスを作成できます。また、さまざまな種類のエンドポイントが必要なので、Bindings 用のフォルダーも用意します。
これらの 3 つのカスタムは現在、私の要件を十分に満たしています。
次に、Bindings/Host/Instance のサンプル コード スニペットをいくつか教えてください。
私はあなたが何を意味するのか分かりません
サービスを柔軟な環境でホストしたい
と
Service > Host フォルダーにカスタム ホスティング ロジックを配置したい
使用されるホスティング コンテナーのタイプは、サービス実装が参照されるプロジェクトのタイプ (Web、コンソール、Windows サービスなど) によって異なります。これは、1 つのプロジェクトにバンドルするものではなく、別のプロジェクト (または、異なるサービス インスタンスごとに異なるソリューションを使用することもできます。
そして、これは一般的なソリューション構造につながります。コントラクトをプロジェクトとしてソリューションに配置することで、コントラクト アセンブリ ビルド (および場合によっては展開) をソリューションのビルドと展開に結合します。コントラクトは、サービスの実装とは別に構築および管理できるように、理想的には独自のソリューションに含める必要があります。契約の複数のバージョンを維持する必要がある場合はどうすればよいでしょうか?
誰にとっても何でもできる汎用サービスを作成するというあなたのアプローチは、複雑すぎると思います。この種の作業は WCF に任せ、少なくともサービスの実装ごとに異なるプロジェクトを作成し、バインディングの管理を展開時に延期する必要があります。
さらに、独自のカスタム バインディング コードを記述しない限り、バインディング用のフォルダーは必要ありません。
バインディングは、エンドポイントを出荷するときに構成で定義できます (そして定義する必要があります)。また、どのトランスポート バインディングを使用するかについての決定は、開発ではなく管理者が行う必要があります。