2

記事ごとに、IISでIOCコンテナー（Unity、Windsorなど）を使用することについての議論には、カスタムServiceHostFactoryとカスタムServiceHostの作成が含まれます。

そのために私が見ることができる唯一の理由は、IInstanceProvider関連のペイロードを持つカスタムサービスの動作をすべてのサービスに適用できるようにするためです。だから私は、匿名のサービス構成を持っていることによって全体の事柄が単純化されない理由を理解しようとしています。このような構成により、カスタムServiceHostFactoryおよびカスタムサービスホストを使用せずに、カスタム動作をすべてのサービスに適用できます。

とはいえ、カスタムサービスホストが必要になると私が想像できる唯一の理由は、カスタムIInstanceProviderが各WCFインスタンスまたはコンテキストインスタンスでリサイクルされるかどうかです。確かに、IOCコンテナーのバインディングは、IIS ServiceHostを起動するたびに、繰り返しまたは不定期に確立するのではなく、1回だけ確立する必要があります。

カスタムIInstanceProviderが実際に散発的にリサイクルされている場合は、IOCコンテナーをカスタムサービスホストに配置して、可能な限り長く存続するようにすることができます。

しかし、繰り返しになりますが、カスタムIInstanceProviderが組み込みのサービスホストと同じくらい長く続く場合は、カスタムサービスホストファクトリとカスタムサービスホストをスキップしないのはなぜですか？

実際、これをもう少し進めて、IOCコンテナをカスタムIInstanceProviderの静的メンバーに入れる場合、IInstanceProviderが不規則にリサイクルされていても問題ありません。それは完全な円になります：なぜカスタムServiceHostFactoryとカスタムServiceHostがWCFでIOCコンテナを使用する必要があるのですか？

4

3 に答える 3

2

個人的にはServiceHostFactory、 、ServiceHost、ServiceBehavior、および のInstanceProvider組み合わせを必要とせず、.svc ファイルにファクトリを登録する必要がないデザインを使用するのが好きです。私の WCF サービスは、メッセージ パッシング アーキテクチャ上の非常に薄いレイヤーとして気に入っています。これにより、この WCF 統合機能を使用する手間が省けます。このようなデザインの詳細については、こちらをご覧ください。

于 2012-09-25T13:12:19.693 に答える
2

良い。これは、ほとんどの IoC/WCF 統合 (私のものなど) が、サービスを (依存関係と共に) 作成する以上のことを行うためです。

カスタム ライフタイム / 廃棄

リクエストが終了すると、すべてが適切にクリーンアップされるはずです。サービスと IoC クラスは異なる有効期間を使用します。

の助けだけでは、リクエストの終了を検出することはできませんInstanceProvider。

IContractBehavior / IServiceBehavior

コンテナーにビヘイビアーを登録し、自動的に WCF サービスに追加することができます。

于 2012-08-30T06:28:01.163 に答える
1

興味深い質問です！このようにする唯一の理由は、決して変更されない項目 (つまり、WCF サービスで使用される IoC コンテナー) で app.config を混乱させたくないということです。app.config の使用を、エンドユーザー/開発者が再コンパイルせずに変更したいと考える可能性があるものに制限しようとしています (ほとんどの場合、それほど多くはありません)。これにより、読みやすくなり、構成ファイルとは対照的に、プログラム コード内での Intellisense およびコンパイル時のチェックのサポートが向上するため、通常はプログラムで構成を指定する方が簡単になります。

ただし、この引数は、リンク先の最初の記事には当てはまらない可能性があります。実際には、app.config を使用して IoC コンテナーをセットアップしているためです。したがって、この場合は二重基準になる可能性があります。とにかく、人々が外部構成ファイルを介してすべての依存関係をセットアップしたい理由を本当に理解したことがありません。ほとんどの場合、静的構成を app.config に保存するのはやり過ぎのように思えます。

于 2012-08-29T16:45:45.877 に答える