No. One of the MVVM core principles is designer support. The principle is called "Blendability" after the Expression Blend designer (resp Blend for Visual Studio) tool. Note, that Visual Studio uses the same designer.
With MVVM you can achieve much better design time support by databinding to design time data. For example, you in DataGrid or ListBox you can see in the designer how the actual items looks like when databound.
Breaking the designer has nothing to do with complexity of bindings.
You just need to follow few simple principles and understand what's going on in the designer.
First of all, Visual Studio designer creates instance of the ViewModel in the designer process. You need to be careful, that you don't execute such code in the viewmodel, that could break the designer. Here are some examples:
Don't do this
This will break the designer, because Visual Studio Designer is not allowed to do DB calls.
//ctor
public MyViewModel()
{
using(var db = new MyDbContext()} ... //
}
calling DB, or FileSystem in constuctor is bad practice anyway
this breaks the designer, because VS Designer does not have access to your configuration
//ctor
public MyViewModel()
{
string configValue = ConfigurationManager.AppSettings["SomeProperty"]
}
if you databind to a property, the getter is acually executed. This code breaks the designer, because App.Current is the Visual Studio Designer, not your app! Be carefull about it.
public class MyViewModel
{
public string SomeProperty
{
get { return App.Current.MainWindow.SomeProperty; }
}
}
This will cause NullReferenceException when binding to CountOfItems, because VS Designer doesn't call Load()
public class MyViewModel
{
private List<string> _items;
public void Load()
{
_items = new List<string>{ "Item1", "Item2" }
}
public int CountOfItems
{
get { return _items.Count; }
}
}
Good practices
Just check if you are in the design mode wherever needed:
//ctor
public MyViewModel
{
bool IsDesignMode => DesignerProperties.GetIsInDesignMode(new DependecyObject());
public MyViewModel()
{
if (IsDesignMode)
{
//this will be shown in the designer
Items = new List<string>{ "Item1", "Item2" }
}
}
//INotifyPropertyChanged details ommited due to simplification
public List<string> Items {get; private set;}
public void Load()
{
//optionally you may check IsDesignMode
using (var db = new MyDbContext())
{
this.Items = db.Items.Select(i => i.Name).ToList();
}
}
}
I've created code snippet, where I use this pattern:
d:DataContext="{d:DesignInstance Type=local:MyViewModelDesignTime, IsDesignTimeCreatable=True}"
I don't actually instantiace the ViewModel directly, but I inject DesignTime version of the viewmodel:
public class MyViewModel()
{
protected MyViewModel()
{
//both runtime and design time logic.
//you may use IsDesignMode check if needed
}
public MyViewModel(ISomeExternalResource externalResource) : this();
{
//this is executed only at run time
_externalResource = externalResource;
Items = externalResouce.GetAll();
}
public List<string> Items {get; protected set;}
}
public class MyViewModelDesignTime : MyViewModel
{
public MyViewModelDesignTime () : base()
{
//this will be show in the designer
Items = new List<string> { "Item1", "Item2" };
}
}
If your designer breaks anyway and you don't know why, you can attach another instance of visual studio to the xaml designer process and it will nicelly show the problematic line of code.
Last, but not least, you can easily turn off instanciating the ViewModels. Just set IsDesignTimeCreatable=false
in d:DataContext
Recapitulation
- Check all the code execution paths of your viewmodel which can be executed by the xaml
designer process
- Do not access database, webservices or filesystem in those execution paths
- Do not access static resource, e.g. Application.Current, because thay may not be initialized properly
- Check all getters of properties that are databound. They may trie to return something that was not initialized by the designer.
- Use branching (e.g. if..else) for the designer and runtime execution paths
- Always generate some fake design-time data