c# - Dependency Injection - Clean way to handle multiple injections -

i'm pretty new di , have few questions hoped people clear me, i'm working on wpf-mvvm system uses caliburn micro, using mef container.

this application used keep track of shipments , has several parts. hope can explain enough, please point out if is't clear.

i have several entities returned database (via webservices) examples shipments, containers, packages.

for each of these entities have model wraps webservice entity, , manager, manager responsible standard crud operations via webservices, storing observablecollection of model, these managers injected constructors of viewmodels require access these lists.

so, have shipment > shipmentmanager > shipmentlistviewmodel, done allow multiple viewmodels work same list of shipments

however, i've started run issues viewmodels have constructors 6+ managers included, , cases used pass onto newly constructed dialog viewmodels.

i'm hoping suggest clean solution issue, i'm thinking of single class become container managers, , can inject container class , use desired manager, i've seen people advising against method, without stating why.

also, 1 other question, models implement ieditableobject , because managers responsible maintaining list of models, saving changes models, publishing event inside endedit manager picks issue?

edit: code requested:

the bootstrapper create , exports required classes:

        protected override void configure()     {         container = new compositioncontainer(new aggregatecatalog(assemblysource.instance.select(x => new assemblycatalog(x)).oftype<composablepartcatalog>()));          compositionbatch batch = new compositionbatch();         ieventaggregator eventaggregator = new eventaggregator();         batch.addexportedvalue<iwindowmanager>(new windowmanager());         batch.addexportedvalue<ieventaggregator>(eventaggregator);         batch.addexportedvalue<imanager<shipmentcontainer>>(new containermanager());         batch.addexportedvalue<imanager<item>>(new itemmanager());         batch.addexportedvalue<imanager<ordereditem>>(new ordereditemmanager());         batch.addexportedvalue<imanager<package>>(new packagemanager());         batch.addexportedvalue<imanager<proforma>>(new proformamanager(eventaggregator));         batch.addexportedvalue<imanager<project>>(new projectmanager());         batch.addexportedvalue<imanager<shipment>>(new shipmentmanager(eventaggregator));         batch.addexportedvalue<imanager<packingitem>>(new packinglistmanager(eventaggregator));         batch.addexportedvalue(container);          container.compose(batch);     } 

contentviewmodel handled menu clicks, allows opening of several diaglogs, constructor contains large number of di:

    public lblcontentviewmodel(iwindowmanager windowmanager, imanager<project> pmanager, ieventaggregator eventmanager, imanager<item> imanager, imanager<packingitem> plmanager, imanager<shipment> smanager)         {           ...         } 

and dialogs shows follows:

 public void openproject()     {         projectsearchviewmodel viewmodel = new projectsearchviewmodel(_eventaggregator, _projectmanager);         this._windowmanager.showdialog(viewmodel);     } 

hopefully code wanted see charleh, if not please let me know , i'll try , provide needed.

i'm making few assumptions here but:

is there preventing having dialogs specify dependencies , have dependencies resolved container?

it sounds manager classes singleton lifestyle (correct me if i'm wrong); if case, vms cause dialogs shown don't need take dependency managers aren't interested in: dialog should resolve these dependencies upon instantiation (once again assumption dialogs transient)

srp states objects should have single responsibility; whilst sounds making class that's responsible containing more classes single responsibility, creating container, ioc container doing.

could post example code or clarify how have ioc setup - singleton, transient? ioc containers have factory options (such castle windsors typedfactory) give more control on transient instantiation might option (depends on complexity)

edit: ok after seeing code solution simple enough...

if aren't doing so, export viewmodels in mef.

the container should able resolve vms components too. don't worry number of exports. i'm not sure if mef supports convention based registration (quick search suggests degree i'm not sure)

once you've exported vms, can mef instantiate , satisfy dependencies when vm required

when need instance of vm can use static ioc class provided in cm (it resolves container)

var vm = ioc.get<projectsearchviewmodel>() 

and show vm in dialog

_windowmanager.showdialog(vm); 

you go 1 better , move dependency projectsearchviewmodel constructor of main vm it's more clear cut (but either way work)

since dependencies being satisfied upon instantiation, dialog can specify dependent on without parent window needing know

the lblcontentviewmodel constructor becomes less bloated:

 public lblcontentviewmodel(iwindowmanager windowmanager, ieventaggregator eventmanager)  {      ...  } 

and projectsearchviewmodel correctly specifies it's dependencies

public projectsearchviewmodel(ieventaggregator eventaggregator, imanager<project> projectmanager) {     ... } 

and inversion part of ioc - components , subcomponents specify require , container provides. other way round component deciding subcomponents require...which have been painful going forward!