.net - How best to implement a Per-View Life-Cycle for IoC Injected Components -

i working on wpf application using mvc architecture , ioc container. presently, wrestling design issue involving scope , lifetime of container provided components. here situation.

i generalize saying incorrectly ioc containers support 2 component life cycles, singleton , transient. need middle ground sets of components.

consider view displays list of records in grid. when user clicks on record, new view opens display record details , allow editing. user can have many such views open, each displaying different record. each view gets own model , controller well.

within context of given model-view-controller set, there components such dialogs both transient , lazily injected. want new instance each time need display 1 , since of these transients needed if user takes action, inject factory delegate. delegate invoked needed perform actual dependency resolution.

beyond model, view , controller, there host of other components want 1 instance per m-v-c set. example, implementing nhibernate conversation pattern calls session opened when view opens , remain open until closes. likewise, each set needs own shared event broker , potentially few "other things." if these dependencies resolved @ moment view created, not problem. declare of them transient , done it.

however, of lazily resolved dependencies have dependencies on model, controller or "other things." problem is, when resolving lazy dependency, container behind delegate needs inject right instance of each dependency. of course implies delegate somehow tied m-v-c set, should not issue if larger problem can resolved.

now above said oversimplifying list of supported life cycles. containers support intermediate life cycles such per-thread or pre-request, allow scoping conceptually similar looking for. these not apply in interactive ui scenario though. not case each view on own thread or in other convenient context provides basis scoping.

thus question is, best way implement per-view (or per arbitrary context) component life cycle using ioc container. our present container unity have abstracted ourselves enough switch without difficulty. if more readily implemented in, or implemented out of box container, consider switching.

the pattern describe unit of work. correct in defined web requests, incorrect in stating not apply interactive ui scenarios. view context scoping - know when move , away it, , points @ respectively create , destroy child containers:

1. move view
2. create child container view
3. resolve view instance child container
4. do work
5. destroy child container
6. move away view