I have a viewmodel which extends a base class called BaseModel which in turn has a property of type DbContext.
How do I get ninject to inject the DbContext into the base class when calling the drived class?
I have a viewmodel which extends a base class called BaseModel which in turn has a property of type DbContext.
How do I get ninject to inject the DbContext into the base class when calling the drived class?
The most reliable way is to make it a required constructor parameter:
public abstract class BaseModel
{
private DbContext dbContext;
protected BaseModel(DbContext dbContext) { this.dbContext = dbContext; }
protected DbContext DbContext { get { return this.dbContext; } }
}
Then in your view models, simply pass the DbContext into the base class:
public CustomerViewModel : BaseModel
{
public CustomerViewModel(DbContext dbContext)
: base(dbContext) { }
}
It sounds like you don't quite understand how to use Ninject properly, for the example I have given, all you need to do is register 1 binding
kernel.Bind<DbContext>().To<MyDbContext>(); // Or whatever your DbContext is called.
Then you can resolve the view model like this:
var viewModel = kernel.Resolve<CustomerViewModel>();
You would only need to register a binding for CustomerViewModel
if you needed to resolve that as a dependency for another class.
Make sure the base class' property is
For example:
abstract class AbstractFoo
{
[Ninject.Inject]
public DbContext DbContext { get; set; }
}
Also see the Ninject Wiki on Property Injection
(For future readers: This is not really in regard to the original question but needs answering because the poster was unaware of when bindings need to be created.)
Also, you will need a binding per type you want to be injected into some other type (or resolved directly from the kernel).
Given the following:
public class DerivedFoo : AbstractFoo
{
}
and some class Service
where it should be injected into:
public class Service
{
public Service(DerivedFoo foo)
{ ... }
}
requires a binding like:
Bind<DerivedFoo>().ToSelf();
Hint: well actually in this exact case the binding is not necessary, since with ninject's default configuration, if the type to resolve - in this case the constructor parameter DerivedFoo foo
is a class with accessible constructor (abstract class
=> would not be accessible!), then ninject behaves as if you would have created the above binding. You can disable this behavior so that ninject only resolves types you've actually created a binding for.
If the service would look slightly different, let's say:
public class Service
{
public Service(AbstractFoo foo)
{ ... }
}
you would need a binding like
Bind<AbstractFoo>().To<DerivedFoo>();
Also in the following case where an interface is injected instead of a class, you would need a binding:
public class Service
{
public Service(IFoo foo)
{ ... }
}
Bind<IFoo>().To<DerivedFoo>();
In some cases it makes sense to use Ninject.Extensions.Conventions in order to reduce the amount of Bind...
code you need to write.
Note however, that conventions should be specific and easy to remember, and they should not overlap (overlap = multiple conventions apply to the same type).
Also look at this SO question for some more information regarding convention bindings.