Design – Desktop application, dependency injection

dependency-injectiondesignservice-locatoruser interface

I am thinking of applying a real dependency injection library to my toy C#/GTK# desktop application. I chose NInject, but I think this is irrelevant to my question.

There is a database object, a main window and several utility window classes. It's clear that I can inject the database into every window object, so here DI is useful. But does it make sense to inject utility window classes into other window classes?

Example: I have classes such as:

class MainWindow {…}
class AddItemWindow {…}
class AddAttachmentWindow {…}
class BrowseItemsWindow {…}
class QueryBuilderWindow {…}
class QueryBrowserWindow {…}
class PreferencesWindow {…}
…

Each of the utility classes can be opened from MainWindow. Some utility windows can also be opened from other utility windows. Generally, there might be a really complex graph of who can open whom. So each of those classes might need quite a lot of other window classes injected. I'm worried that such usage will go against the suggestion not to inject too many classes at once and become a code smell. Should I use some kind of a service locator object here?

Best Answer

I'd suggest a UtilityWindowOpener class. Its methods will open the various utility windows. Then you can just inject a UtilityWindowOpener anywhere you may need to open a utility window. The UtilityWindowOpener will then have the various utility windows injected (or possibly create them on demand, that's hidden behind the interface). It'll also bring all navigation logic into fewer locations.

Related Solutions

Ninject DI – How to Pass Initialization Data at Runtime

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.

C# Dependency Injection – Multiple Instances or Single InRequestScope

In theory, you should only get one instance, unless you made an error in your DI-registration.

To check what's happening, just put a breakpoint inside the UnitOfWork-class' constructor. Each time it hits, a new UnitOfWork is constructed.

Related Topic