Когда я должен использовать UserControl вместо Page? - PullRequest
8 голосов
/ 12 апреля 2010

Я замечаю, что многие из фреймворков WPF MVVM, похоже, избегают использования элементов управления NavigationWindow и Page в пользу создания страниц с использованием вложенных элементов UserControls.

NavigationWindow и Page обеспечивают простые способы включения навигации по журналу назад и вперед, а также обеспечивают простой способ передачи данных между страницами. Большинство каркасов MVVM, которые я видел, реализуют эти функции различными способами.

Есть ли конкретная причина избегать использования NavigationWindow и Page?

Ответы [ 4 ]

10 голосов
/ 12 апреля 2010

"NavigationWindow не хранит экземпляр объекта содержимого в история навигации. Вместо, NavigationWindow создает новый экземпляр объекта контента каждый время, к которому осуществляется переход с помощью история навигации. Такое поведение разработан, чтобы избежать чрезмерной памяти потребление при больших количествах и большие куски контента в настоящее время переместился в. Следовательно, государство из содержания не запоминается из одна навигация к следующей. Тем не мение, WPF предоставляет несколько методов который вы можете хранить кусок состояния для части контента в навигации история .... "

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

3 голосов
/ 17 июня 2010

Я только что обнаружил еще одно различие между UserControls и Pages: страницы не могут использоваться в качестве шаблонов данных.

Например, если вы создавали приложение с использованием стиля MVVM, вы можете ожидать, что это сработает:

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

Но если ProjectDashboardView - это страница, он потерпит неудачу.

2 голосов
/ 21 апреля 2010

Я только что нашел другую интересную информацию, связанную с WPF NavigationWindow и Page на веб-сайте Пола Стовелла.

Он может сказать следующее о классе NavigationWindow:

WPF включает в себя класс NavigationWindow, который по сути является окном, которое также удваивается как фрейм, реализуя большинство тех же интерфейсов. Поначалу это звучит полезно, но в большинстве случаев вам нужен больший контроль над окном, поэтому у меня никогда не было необходимости использовать этот класс. Я просто указываю на это для полноты картины, хотя ваш пробег может отличаться.

См. Его углубленную статью о WPF Navigation и проблемах управления страницей Magellan и WPF , с которыми он столкнулся при написании своей среды Magellan WPF.

1 голос
/ 12 апреля 2010

Ну, вы все еще собираетесь использовать пользовательские элементы управления для создания многократно используемых подкомпонентов, но что касается архитектуры приложения, то в действительности все сводится к случаю использования. Если вы создаете типичное веб-приложение, приложение Business / Navigation должно подойти. Если вы пишете игру, не так много. Аналогично, если вы делаете что-то вроде интерактивной рекламы или медиаплеера.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...