2016-06-21 5 views
0

У меня есть класс ViewModel как этотDesign Time Интерфейс передачи данных Реализация

public class MyViewModel : ViewModelBase 
{ 
    public MyViewModel() 
    { 
     if (!IsInDesignMode) 
     { 
      throw new InvalidOperationException(); 
     } 
    } 

    public MyViewModel(IDataProvider dataProvider) 
    { 
     Data = new ObservableCollection<IData>(dataProvider.GetData()); 
    } 

    public ObservableCollection<IData> Data { get; private set; } 
} 

Теперь я хочу, чтобы создать некоторые данные о времени проектирования. В моих модульных тестах я использую mocking framework (Moq) для этого. Мне не нравится тот факт, что мне нужно создать некоторую реализацию Mock для IData в моем проекте приложения или ссылку и использование среды Mocking.

Каков самый элегантный способ получить данные о времени разработки в таком сценарии?

Edit: Не уверен, если это уместно, но я использую Visual Studio 2012.

ответ

1

В основном вы создаете заглушки, а не макет для данных времени разработки. У заглушки не могут быть введены какие-либо зависимости.

public class MyDesignViewModel : ViewModelBase 
{ 
    public MyViewModel() 
    { 
     Data = new ObservableCollection<IData>(new List<IData>() 
     { 
      new MyData() { Value1 = 1, Value2 = "Test" }, 
      ... 
     }); 
    } 

    public ObservableCollection<IData> Data { get; private set; } 
} 

Затем используйте его в XAML как это:

<UserControl x:Class="MyView" 
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
    mc:Ignorable="d" 
    d:DataContext="{d:DesignInstance Type=vm:MyDesignViewModel, IsDesignTimeCreatable=True}"> 
+0

Так что нет никакой магии путь вокруг создания двух новых классов '' MyDesignViewModel'and MyData'in мои приложения проекта, правильно? – metacircle

+0

Просто 'MyDesignViewModel', для' MyData' вы можете использовать существующую реализацию (я не могу ее видеть из опубликованного кода, просто ознакомьтесь с интерфейсом), если ваша реализация не нуждается в каких-либо зависимостях (и нет причин это должно быть в 98% случаев). Все остальное заканчивается смешением проблем (зависимостей или жесткой связи, которые не связаны с фактической задачей ViewModel) или слишком большим расслаблением системы (т. Е. Путем создания экземпляров ViewModels с помощью конструктора без параметров). Ваш DesignViewModel может находиться в другой сборке, чем ваши модели просмотра, только для ваших дизайнеров пользовательского интерфейса – Tseng