2016-06-21 11 views
0

Ich habe eine Viewmodel Klasse wie diesesDesign Time Data Interface Implementation

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; } 
} 

Jetzt habe ich einige Design-Zeitdaten erstellen möchten. In meinen Unit-Tests verwende ich ein Mocking Framework (Moq), um dies zu tun. Ich mag die Tatsache nicht, dass ich eine Mock-Implementierung von IData in meinem App-Projekt erstellen oder das Mocking-Framework referenzieren und verwenden muss.

Was ist die eleganteste Art, in einem solchen Szenario Daten zur Entwurfszeit zu erhalten?

Edit: Nicht sicher, ob es relevant ist, aber ich bin mit Visual Studio 2012.

Antwort

1

Grundsätzlich erstellen Sie einen Stummel, nicht ein Modell für Design Zeitdaten. Der Stub kann keine Abhängigkeiten enthalten.

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; } 
} 

Dann ist es in XAML verwenden wie folgt aus:

<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

So gibt es keine magische Art und Weise zwei neue Klassen 'um die Schaffung MyDesignViewModel'and' MyData'in meine Anwendungen Projekt, richtig? – metacircle

+0

Nur 'MyDesignViewModel', für' MyData' können Sie Ihre vorhandene Implementierung verwenden (ich kann es nicht aus dem Code sehen, sehen Sie nur die Schnittstelle), wenn Ihre Implementierung keine Abhängigkeiten benötigt (und es gibt keinen Grund es sollte in 98% aller Fälle). Alles andere endet im Mischen von Belangen (Abhängigkeiten oder enge Kopplung, die nicht mit der tatsächlichen Aufgabe von ViewModel zusammenhängen) oder zu viel Lockerung des Systems (d. H. Indem ViewModels mit einem parameterlosen Konstruktor instanziiert wird). Ihr DesignViewModel kann sich in einer anderen Assembly befinden als Ihre ViewModels nur für Ihre UI-Designer – Tseng