Question

I’m increasingly finding myself mixing runtime parameters and implicit construction injection and it smells bad to me.

Example – I have a base class describing a Filter, and various inherited types for specific filters (tag, category, date, author, etc etc)

var filter = StructureMap.ObjectFactory
.With("caption").EqualTo("Posts filtered by tag:")
.With("parameters").EqualTo(parameters)
.With("displayInSummary").EqualTo(true)
.GetInstance<TagListFilter>();

The reason I do this is because in the constructor I have an interface using which I wish StructureMap to inject a concrete class (IArticleConfigurator):

public TagListFilter(string caption, IDictionary<string,string> parameters, bool displayInSummary, IArticleConfigurator configurator)
:base(caption, parameters,displayInSummary, configurator)

But it just occured to me that I replaced a simple constructor, albeit with a concrete class instead of interface, with, essentially, the same thing but using DI to inject 1 concrete type. I’m doing this because currently our configs are in a xml file but will be moved to a CMS, so seemed like a good idea to use an interface.

It seems wrong and not in the spirit of DI.

Should I use a factory to generate my various filters? If so, can I still leverage DI to get a concrete instance of my IArticleConfigurator?

Answer 1

You shouldn’t pass parameters explicitly from one dependency to another or, at least, you should minimize their number. One big disadvantage of resolving instances with parameters is that you specify parameter names as string literals – which make you code very fragile in changes of constructor signature.

One example I might think of (note that I have no clue regarding your domain and responsibilities of entities) is to inject provider or, as you already said, factory. For example, create something like ITagListFilterConfigurationProvider (you should change the name as you want to, I just trying to give motivation). You might create very abstract provider like IFilterConfigurationProvider with three methods as below, if you have same parameters for filters:

interface ITagListFilterConfigurationProvider
{
    string Caption { get; }
    IDictionary<string,string> GetParameters();
    bool IsDisplayInSummary { get; }
}

Now you constructor will look like:

public TagListFilter(ITagListFilterConfigurationProvider configurationProvider, IArticleConfigurator configurator)

All you need is to implement it as you already did (because you are passing concrete parameters to constructor) and extract this behaviour to provider. What is left – is to register concrete provider with StructureMap and resolve filter without passing any concrete parameters

var filter = StructureMap.ObjectFactory.GetInstance<TagListFilter>();