Ninject を使用して、WCF サービスの DI を正常に構成しました。各サービス クラスには、Ninject が実行時にインスタンスを挿入するコンストラクターがあります。
public class MessageService : ServiceBase,IMessageService
{
private readonly IMessageRepository _messageRepository;
private readonly IMappingEngine _mapper; // AutoMapper mapping engine
// Instances injected in constructor by Ninject
public MessageService(IMessageRepository messageRepository, IMappingEngine mapper)
{
_messageRepository = messageRepository;
_mapper = mapper;
}
...
}
私の理解では、これは Wcf に NinjectServiceHostFactory を使用してサービスをアクティブ化するように指示することによって達成されるということです。
すべて順調です...それは御馳走になります。
wcf サービス プロジェクトによって参照されるクラス ライブラリが多数あります。これらのライブラリの 1 つには、ClaimsAuthenticationManager から派生したクラスがあります。着信クレームをドメイン固有のものに変換するように設計されています。WCF スキャフォールディングは、ID パイプラインの一部として実行時にこのクラスをインスタンス化します。このクラスでリポジトリ パターンを使用して、データベースから ID のビジネス ロールを取得したいと考えています。次に、ドメイン固有のクレームを使用して新しい ClaimsIdentity を作成します。これで、リポジトリ インスタンスを新しく作成できましたが、実行時に Ninject にこれを注入してもらいたいと思います。私は、Ninject がそれを実行してくれるというまったく単純な希望で、リポジトリ インターフェイス パラメーターを使用してコンストラクターを作成しました。パラメーターなしのコンストラクターが見つからなかったため、WCF が失敗しました。
クラス ライブラリ内に Ninject カーネルへの参照が基本的にない場合、Ninject にインスタンスを注入させるにはどうすればよいですか?
私の理解では、IoC コンテナーはコンポジション ルート (私の場合は WCF サービス ホスト内) に作成する必要があります。私のクラスをインスタンス化しているのは Wcf パイプラインであるため、依存関係を結び付けるためにプロセスを制御することはできません。それとも私ですか?