Какие подходы доступны для фиктивных данных времени разработки в WPF?

Question 1

Я работаю без наложения выражений и просто использую редактор XAML в vs2010. Помимо мудрости этого, я все чаще вижу потребность в привязке данных во время разработки. В простых случаях FallbackValueсвойство работает очень хорошо (текстовые поля, текстовые блоки и т. Д.). Но особенно при работе с ItemsControlи т.п. действительно нужны образцы данных, которые будут видны в дизайнере, чтобы вы могли настраивать и настраивать элементы управления и шаблоны данных без необходимости запускать исполняемый файл.

Я знаю, что это ObjectDataProviderпозволяет привязать к типу и, таким образом, может предоставлять данные времени разработки для визуализации, но тогда есть некоторая манипуляция, позволяющая привязать реальные данные времени выполнения без потери ресурсов путем загрузки загрузки как времени разработки, так и времени разработки, фиктивные данные и привязки времени выполнения.

На самом деле я хочу иметь возможность, скажем, «Джон», «Пол», «Джордж» и «Ринго» отображаться в конструкторе XAML как стилизованные элементы в моем ItemsControl, но чтобы реальные данные отображались, когда приложение бежит.

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

Итак, мои вопросы:

1. Как можно использовать привязки коллекций и нетривиальных данных во время разработки в конструкторе XAML Visual Studio, а затем плавно переключиться на привязки времени выполнения?

2. Как другие решили эту проблему данных во время разработки и во время выполнения? В моем случае я не могу легко использовать одни и те же данные для обоих (как можно было бы, скажем, с запросом к базе данных).

3. Могу ли я использовать их альтернативы смеси выражений для проектирования XAML с интегрированными данными? (Я знаю, что есть несколько альтернатив, но мне конкретно нужно что-то, что я могу использовать, чтобы увидеть связанные образцы данных и т. Д.?)

Question 2

Используя VS2010, вы можете использовать атрибуты времени разработки (работает как для SL, так и для WPF). В любом случае у меня обычно есть фиктивный источник данных, так что это просто вопрос:

Добавление объявления пространства имен
```
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
```
Добавление контекста фиктивных данных в ресурсы окна / управления
```
<UserControl.Resources>
  <ViewModels:MockXViewModel x:Key="DesignViewModel"/>
</UserControl.Resources>
```
Установка контекста данных времени разработки
```
<Grid d:DataContext="{Binding Source={StaticResource DesignViewModel}}" ...
```

Работает достаточно хорошо.

Question 3

Как сочетание принятого ответа Горана и отличного комментария Рене.

Добавьте объявление пространства имен. xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
Ссылка на контекст данных времени разработки из кода.
<Grid d:DataContext="{d:DesignInstance Type=ViewModels:MockXViewModel, IsDesignTimeCreatable=True}" ...

Question 4

Карл Шиффлетт описывает подход, который должен одинаково хорошо работать для VS2008 и VS2010:

Просмотр данных времени разработки в Visual Studio 2008 Cider Designer в проектах WPF и Silverlight

У Лорана Бюньона есть аналогичный подход, основанный на Expression Blend. Это может сработать для VS2010, но я еще не подтвердил это.

Моделирование данных в режиме разработки в Microsoft Expression Blend

Question 5

Возможно, вам подойдут новые возможности Visual Studio 2010 и Expression Blend 4 во время разработки.

Как это работает, показано в примере приложения BookLibrary платформы WPF Application Framework (WAF) . Загрузите версию .NET4.

Question 6

Я использую этот подход для создания данных времени разработки с помощью .NET 4.5 и Visual Studio 2013.

У меня только одна ViewModel. Модель представления имеет свойство, IsInDesignModeкоторое сообщает, активен ли режим разработки или нет (см. Класс ViewModelBase). Затем вы можете настроить данные времени разработки (например, заполнение элемента управления элементами) в конструкторе моделей представления.

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

public abstract class ViewModelBase
{
    public bool IsInDesignMode
    {
        get
        {
            return DesignerProperties.GetIsInDesignMode(new DependencyObject());
        }
    }
}

public class ExampleViewModel : ViewModelBase
{
    public ExampleViewModel()
    {
        if (IsInDesignMode == true)
        {
            LoadDesignTimeData();
        }
    }

    private void LoadDesignTimeData()
    {
        // Load design time data here
    }       
}

Question 7

Используя Visual Studio 2017, я пытался следовать всем руководствам и вопросам, подобным этому, и все еще сталкивался с проблемой, <ItemsControl>которая просто не выполняла код, который у меня был внутри конструктора, DesignFooViewModelкоторый наследуется от FooViewModel. Я подтвердил, что "не выполнено", следуя этому "удобному" руководству MSDN (спойлер: MessageBoxотладка). Хотя это не имеет прямого отношения к исходному вопросу, я надеюсь, что это сэкономит другим много времени.

Оказывается, я не делал ничего плохого. Проблема заключалась в том, что мое приложение нужно было создавать для x64. Поскольку Visual Studio в 2018 году все еще является 32-разрядным процессом и, по-видимому, не может запускать 64-разрядный хост-процесс для конструкторской части, он не может использовать мои классы x64. На самом деле плохо то, что ни в одном журнале нет ошибок.

Итак, если вы наткнетесь на этот вопрос из-за того, что вы видите фиктивные данные в своей модели представления во время разработки (например: <TextBlock Text="{Binding Name}"/>отображается Nameнезависимо от того, установлено ли свойство), причиной, скорее всего, будет ваша сборка x64. Если вы не можете изменить конфигурацию сборки на anycpu или x86 из-за зависимостей, рассмотрите возможность создания нового проекта, который полностью является anycpu и не имеет зависимостей (или каких-либо зависимостей). Таким образом, вы в конечном итоге разделяете большую часть или все части кода, кроме инициализации, из вашего проекта «Приложение WPF» в проект «Библиотека классов C #».

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

Question 8

Подобен ответу с самым высоким рейтингом, но, на мой взгляд, лучше: вы можете создать статическое свойство, чтобы возвращать экземпляр данных проекта и ссылаться на него непосредственно из XAML, например:

<d:UserControl.DataContext>
    <Binding Source="{x:Static designTimeNamespace:DesignTimeViewModels.MyViewModel}" />
</d:UserControl.DataContext>

Это позволяет избежать использования UserControl.Resources. Ваше статическое свойство может функционировать как фабрика, позволяющая создавать нетривиальные типы данных - например, если у вас нет ctor по умолчанию, вы можете вызвать здесь фабрику или контейнер для внедрения соответствующих зависимостей.