1
Vote

View Engines should support IDisposable views

description

WPF views typically shouldn't be IDisposable, but sometimes it is required, especially when subscribing and unsubscribing from events, or releasing child services. Because views may live for a long time or a short time, disposal can be tricky. Some ideas for handling IDisposable views are:
 
  • Windows and dialogs should be disposed when the Closed event is raised. The WindowViewEngineResult could manage this.
  • Composite WPF views shouldn't be disposed - that should be done by a region behavior (todo: blog this)
  • By default, pages are kept in memory even when the page is unloaded. It would be dangerous to dispose the page on unload, so the only solution would be to dispose when the page is removed from the journal. I think I can hook into this. But why keep a page alive that long anyway? This brings me back to [the design flaw in WPF navigation that I blogged about|http://www.paulstovell.com/magellan-page-management].
     
    Related: should this also apply to the Model property, if the Model is IDisposable? Or should the View dispose the Model when called?
     
    I'd like to get a better feel for what the expected behavior for Pages would be. Disposable support for Windows doesn't make sense unless it behaves the same for Pages.

comments