问题
I feel as though I still see a lot of guidance and advice stating that a view-first approach is the best way to go to get Blendability in your application. However, with d:DataContext, d:DesignData and d:DesignInstance, isn't the problem of Blendability easy to solve regardless of how your views and viewmodels are wired together?
With DesignInstance, you simply pick a concrete ViewModel type to be used in the designer, and it's as if you've got view-first composition. In fact, using DesignInstance actually allows for better separation of concerns than doing IsInDesignMode backflips or creating a default constructor just for design support in your real viewmodel - you can inherit from your viewmodel type or from a common interface type to create a simple "designer" viewmodel, and it's fully constrained to the designer. With DesignData, you don't even have to do that: you can just create a fake viewmodel declaratively in XAML.
True, there is a small up-front cost in doing the above activities, but the result is actually a cleaner separation than what you'd get by mixing in design data with your real viewmodel. Is there something I'm missing? Why is Blendability still such a big concern?
回答1:
If you have mockup data, for an entire view, then using d:DataContext,d:DesignData and d:DesignInstance should give you blendability.
So the answer to your question is, in short, it doesn't matter how you use a view at runtime (view first or viewmodel first), you can still have blendablility. If you have some viewmodel logic or initialization in your runtime version, you should just make sure that the same is in your design-time instance.
Many people are trying to find a way that they don't need to duplicate work by creating essentially two viewmodels. I do agree that it does give better separation as well.
来源：https://stackoverflow.com/questions/3619031/blendability-with-ddatacontext-what-am-i-missing