I have the following two classes:
public class StoreService : IStoreService
{
private IEmailService _emailService;
public StoreService(IEmailService emailService)
{
_emailService = emailService;
}
}
public class EmailService : IEmailService
{
}
Using Ninject I can set up bindings no problem to get it to inject a concrete implementation of IEmailService into the StoreService constructor. StoreService is actually injected into the code behind of an ASP.NET WebForm as so:
[Ninject.Inject]
public IStoreService StoreService { get; set; }
But now I need to change EmailService to accept an object that contains SMTP related settings (that are pulled from the ApplicationSettings of the Web.config). So I changed EmailService to now look like this:
public class EmailService : IEmailService
{
private SMTPSettings _smtpSettings;
public void SetSMTPSettings(SMTPSettings smtpSettings)
{
_smtpSettings = smtpSettings;
}
}
Setting SMTPSettings in this way also requires it to be passed into StoreService (via another public method). This has to be done in the Page_Load method in the WebForms code behind (I only have access to the Settings class in the UI layer).
With manual/poor mans DI I could pass SMTPSettings directly into the constructor of EmailService and then inject EmailService into the StoreService constructor. With Ninject I don’t have access to the instances of injected types outside of the objects they are injected to, so I have to set their data AFTER Ninject has already injected them via a separate public setter method. This to me seems wrong.
How should I really be solving this scenario?
With manual/poor mans DI I could pass SMTPSettings directly into the
constructor of EmailService and then inject EmailService into the
StoreService constructor.
This is also what needs to happen when using Ninject, except that you don’t need to inject these values into the constructors, Ninject will do it for you – it recursively resolves all dependencies you need to obtain a StoreService.
If you declare your EmailService just as you would have when using poor man’s DI, like this:
public class EmailService : IEmailService
{
private SMTPSettings _smtpSettings;
public EmailService(SMTPSettings smtpSettings)
{
_smtpSettings = smtpSettings;
}
}
Now, when asking Ninject for a IStoreService, it will want to instantiate a StoreService.
A StoreService requires an IEmailService, so it will want to instantiate an EmailService.
An EmailService requires an SMTPSettings instance… if Ninject could be told how to obtain such an instance Ninject is able to produce a fully initialized StoreService instance.
I’ve never used Ninject (but I have used other .NET DI frameworks), but from what I can gather from the Ninject docs
one way to do this is to register a factory method that will produce an SMTPSettings instance (https://github.com/ninject/ninject/wiki/Providers%2C-Factory-Methods-and-the-Activation-Context):
using (IKernel kernel = new StandardKernel())
{
kernel.Bind<SMTPSettings>()
.ToMethod(context => new SMTPSettings() /* or any other expression that returns an SMTPSettings instance */);
}
With this binding in place, Ninject should be able to produce a fully initialized StoreService instance.
N.B. I used http://stefanoricciardi.com/2011/01/21/ninject-mini-tutorial-part-1/ to see Ninject in action, maybe it contains some useful information for you as well.
1