Ninject v2.2.1.4 を使用した ASP.NET MVC 3 アプリケーションがあります。すべてがうまく機能していましたが、突然、Ninject がパラメーターなしのコンストラクターに対してパラメーターを持つコンストラクターを使用して DbContext を作成しようとしているのが見え始めました。バインディングは次のとおりです。
kernel.Bind<MyContext>().ToSelf().InRequestScope();
kernel.Bind<IUnitOfWork>().ToMethod(ctx => ctx.Kernel.Get<MyContext>());
kernel.Bind<DbContext>().ToMethod(ctx => ctx.Kernel.Get<MyContext>());
MyContext は、IUnitOfWork インターフェイスも実装する DbContext オブジェクトです。このように設定したので、1 つのリクエストで使用される複数のリポジトリに同じコンテキストが挿入されます。MyContext コンストラクターは次のようになります。
public MyContext() { }
public MyContext(string connectionString) { }
public MyContext (long accountID) { }
public MyContext (Connection connection) { }
すべて同じ MyContext クラスを使用するため、アプリケーションごとに異なるコンストラクターがあります。バインディングを見ると、MyContext クラスが要求されたときにパラメーターなしのコンストラクターが呼び出されると思いますが、何らかの理由でそうではありません。accountID が指定されていなくても、長い accountID パラメータを持つものが呼び出されます。これは明らかにスローされ、「一致するバインディングが利用できず、タイプは自己バインド可能ではありません」という例外ステートメントがスローされます。実際には、IUnitOfWork を生成しようとすると例外がスローされます。
最後の 3 つのコンストラクターをコメント アウトすると、すべて正常に機能し、パラメーターなしのコンストラクターが使用されます。パラメーター化されたコンストラクターのいずれか 2 つをコメントアウトすると、パラメーターなしのコンストラクターではなく、もう一方を使用しようとします。
Ninject が提供する提案は次のとおりです。
Suggestions:
1) Ensure that you have defined a binding for long.
2) If the binding was defined in a module, ensure that the module has been loaded into the kernel.
3) Ensure you have not accidentally created more than one kernel.
4) If you are using constructor arguments, ensure that the parameter name matches the constructors parameter name.
5) If you are using automatic module loading, ensure the search path and filters are correct.
したくないので、1には何もありません。2と5の意味がわかりません。私は、私たちが 3 を実行したとは思いませんし、4 も実行していません。
このシナリオでパラメーターなしのコンストラクターを使用しない理由についての考え。