Dependency injection - passing domain objects to underlying dependencies with NInject

Question

I'm working on a larger project. I hope I understood DI well and based-on that I'm able to do this:

// domain object holding configuration ata
var input = new GeneratorInput
{
    Constructions = new List<Construction>(),
    InitialConfiguration = null,
    MaximalNumberOfIterations = 10
};

// poor-man's-DI solution
var container = new ConfigurationContainer(input.InitialConfiguration);
var constructions = new ConfigurationConstructor(input.Constructions);
var solver = new ConfigurationSolver();
var handler = new ConfigurationHandler(container, constructions, solver);
var generatorContext = new GeneratorContext(container, handler, constructions);
var generator = new Generator(generatorContext, input.MaximalNumberOfIterations);

The GeneratorInput should be created based on UI parameters.

I can't figure out a way to do this via a DI container. I think I want to use NInject.

What is the cleaneast way of doing this please?

Sorry, we do not answer coding issues here on softwareengineering.SE. I suggest you move (not copy!) your question to stackoverflow. Note the SE network has a strong policy against crossposts, so don't forget to delete your question here. — Doc Brown, Aug 12 '17 at 19:59

candied_orange · Accepted Answer · 2017-08-12T22:23:30.777

GeneratorInput should be created based on UI parameters.

This simply means that GeneratorInput can't be constructed until you know what those parameters are.

Poor mans DI, or Pure DI as Mark Seemanns has renamed it, can do this fine on it's own. No container required.

You simply have to be willing to understand that while the composition root (usually this is just main) is the safest place to do construction (and not mix it with behavior code) it's not the only place.

What you need is some code that will be called once those parameters are known. This could be called with a button click. This code represents the composition root for this object. That means this codes responsibility is for constructing this object. It should be focused on that. You only get into trouble if you start adding a bunch of lines that use that object because now you have mixed construction with behavior. Ideally you wont use the object here at all and will instead pass it to something else that will know how to use it.

Separating use and construction is the big benefit DI provides. It helps ensure you're following the Law of Demeter.

Dependency injection - passing domain objects to underlying dependencies with NInject

1 Answers1