8

I notice that many of the WPF MVVM frameworks seem to avoid using the NavigationWindow and Page controls in favor of composing pages using nested UserControls.

The NavigationWindow and Page provide easy ways to enable back and forward navigation in the journal as well as providing an easy way to pass data among pages. Most MVVM frameworks I've seen re-implement these features in various ways.

Is there a specific reason to avoid using NavigationWindow and Page?

dthrasher
  • 40,656
  • 34
  • 113
  • 139

4 Answers4

10

"NavigationWindow does not store an instance of a content object in navigation history. Instead, NavigationWindow creates a new instance of the content object each time it is navigated to by using navigation history. This behavior is designed to avoid excessive memory consumption when large numbers and large pieces of content are being navigated to. Consequently, the state of the content is not remembered from one navigation to the next. However, WPF provides several techniques by which you can store a piece of state for a piece of content in navigation history...."

http://msdn.microsoft.com/en-us/library/system.windows.navigation.navigationwindow.aspx

jasonk
  • 1,580
  • 4
  • 25
  • 33
  • 2
    Good catch. So perhaps the NavigationWindow and Page classes are a bit less relevant to a typical line-of business application. Though it still surprises me that so many MVVM frameworks avoid them completely. – dthrasher Apr 19 '10 at 17:52
3

I just discovered another difference between UserControls and Pages: Pages cannot be used as DataTemplates.

For example, if you were creating application using the MVVM style, you might expect this to work:

    <DataTemplate DataType="{x:Type ViewModels:ProjectDashboardViewModel}">
        <Views:ProjectDashboardView />
    </DataTemplate>

But if the ProjectDashboardView is a Page, it will fail.

dthrasher
  • 40,656
  • 34
  • 113
  • 139
  • In this scenario, you would want your page to either accept a view model in the constructor, or create it from other data. Generally, MVVM implementations would want to use a PageFunction. Inside your page, you may have a content presenter containing the view model. Page is top level component. Try to think of it as an inline Window. – Gusdor May 28 '13 at 11:26
2

I just found some other interesting information related to WPF NavigationWindow and Page on Paul Stovell's website.

He has this to say about the NavigationWindow class:

WPF includes a class called NavigationWindow, which is essentially a Window which also doubles as a Frame, by implementing most of the same interfaces. It sounds useful at first, but most of the time you need more control over the Window, so I've never had any need to use this class. I am just pointing it out for the sake of completeness, though your mileage may vary.

See his in-depth article on WPF Navigation and the Magellan and WPF Page management issues he encountered when writing his Magellan WPF framework.

dthrasher
  • 40,656
  • 34
  • 113
  • 139
1

Well, you're still going to use usercontrols to create reusable sub components, but as for app architecture, it comes down to use case really. If you're building a typical web application a Business/Navigation App should be fine. If you're writing a game, not so much. Likewise if you're doing something like an interactive advert or media player.

Doobi
  • 4,844
  • 1
  • 22
  • 17