MVVM - Должен ли View действительно иметь конструктор по умолчанию?

Question

Я только начинаю работу с шаблоном MVVM в WPF, и я решил, что самый элегантный способ структурировать мой код - внедрить модель представления в конструктор представления.

Это все хорошо, но ReSharper выдает предупреждение в XAML, что у моего представления нет конструктора по умолчанию. Я предполагаю, что это так, чтобы я мог построить свое представление в XAML при необходимости, но это только предположение.

От чего я отказываюсь, требуя, чтобы мой вид взял модель представления в конструкторе?

Редактировать: Мой конструктор представлений выглядит так:

public ExampleView(ExampleViewModel viewModel)
{
    if (viewModel == null) throw new ArgumentNullException("viewModel");
    DataContext = viewModel;
}

Ответ: Я остановился на следующей настройке, где пространство имен DesignTime содержит макеты версий ViewModel для тестирования и поддержки времени разработки.

ExampleView.xaml.cs

public ExampleView()
{
    InitializeComponent();
}

public ExampleView(IExampleViewModel viewModel)
    : this()
{
    DataContext = viewModel;
}

ExampleView.xaml

<UserControl
    x:Class="Wpf.Examples.ExampleView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:DesignTime="clr-namespace:Wpf.Examples.DesignTime">

    <UserControl.DataContext>
        <DesignTime:ExampleViewModel/>
    </UserControl.DataContext>

</UserControl>

Answer 1

Как вы правильно поняли, требование конструктора не по умолчанию будет запрещать вам использовать этот элемент управления из XAML. Это также означает, что дизайн-поддержка больше не будет, и ваши дизайнеры, вероятно, будут вас ненавидеть. Наконец, вы нарушаете все виды хороших сценариев привязки данных. Как использование элемента управления в качестве ItemTemplate.

В качестве исправления для отсутствующей поддержки проектирования , я бы предложил реализовать конструктор по умолчанию, который создает макет модели представления, которая не нуждается в инфраструктуре. Таким образом, вы можете очень элегантно поддерживать режим разработки, и помещение представления в файл XAML (например, для тестирования) сделает что-то разумное.

В качестве исправления для отсутствующей поддержки привязки данных вам следует подумать, не лучше ли использовать модель представления с помощью DataContext элемента управления WPF. Это часто встречается в WPF и - насколько я могу судить - предполагаемый способ передачи модели в представление в WPF.

Answer 2

Чтобы сохранить поддержку дизайнера, вам нужен конструктор по умолчанию. Когда вы определяете свой собственный конструктор, вы в основном теряете автоматически сгенерированный конструктор по умолчанию. Просто создайте явный конструктор по умолчанию, и все будет в порядке.

Answer 3

Предполагая, что вам не нужна поддержка дизайнера, я не вижу причин.