Dependency injection in non trivial WinForm application -


i ask can in introduce dependency injection sample winform app. have application following structure (not complete graph):

mainform <-> mainmodel | |└ -----------------------┐ | └ ------------┐           | fa <-> ma    fb <-> mb    fc <-> mc | |                       |└-----------------┐        | └-----------┐           └----┐             | faa <-> maa   fab <-> mab      fca <-> mca  fcb <-> mcb                                |||                 ┌--------------┘|└----------------┐                fcaa <-> mcaa   fcab <-> mcab   fcac <-> mcac                || ┌--------------┘└----------------┐ fcaaa <-> mcaaa                 fab <-> mab 

i can implement composition root can type this:

var container = new container(); container.registersingle<imainform, mainform>(); container.register<imainmodel, mainmodel>(); container.register<ifa, fa>(); 

...

i know how first mainform , show (simple resovling). still struggling proper logic how create other forms , models on demand. not want pass reference container mainform , resolve dependencies in mainform because smells servicelocator pattern. avoid create obscure factory methods createfa, createfb, createfaaa... avoid pass complete constructed graph mainform too.

furthermore use in mcaa implementation of interface ijob can defined in composition root, avoid pass instance of ijob thru levels of forms or passing kind of factory...

the easiest way how create instances of windows , models , ect. need them using servicelocator... but, well... di?

preferred di: simpleinjector, prefered language: c#

i avoid pass complete constructed graph mainform too.

it make life easier, if design application composed entirely up-front.

if concern related performance, start composing entire graph up-front , measure see if have performance problem @ all. if discover have sub-graphs need defer, you can use virtual proxy pattern defer creation of branches until need them.

if real concern can't create entire graph up-front because sub-graphs depend on run-time values, can use abstract factory; don't have come myriad abstract factory interfaces: single generic interface ifactory<t, tinput> should suffice.

other alternatives selecting dependencies based on run-time values are

furthermore use in mcaa implementation of interface ijob

just inject ijob mcaa other class. don't have pass through layers if layers never create mcaa. composition root needs hold reference implementation, because composition root creates mcaa.


Comments