¿Qué enfoques están disponibles para los datos ficticios en tiempo de diseño en WPF?

Estoy trabajando sin una combinación de expresiones y solo estoy usando el editor XAML en vs2010. Dejando a un lado la sabiduría de esto, cada vez veo más la necesidad de vincular datos en tiempo de diseño. Para casos simples, la FallbackValuepropiedad funciona muy bien (Textboxes y TextBlocks, etc.). Pero especialmente cuando se trata de ItemsControly similares, uno realmente necesita que los datos de muestra sean visibles en el diseñador para que pueda ajustar y modificar los controles y las plantillas de datos sin tener que ejecutar el ejecutable.

Sé que ObjectDataProviderpermite la vinculación a un tipo y, por lo tanto, puede proporcionar datos en tiempo de diseño para visualizar, pero luego hay algunos malabarismos para permitir que los datos reales en tiempo de ejecución se vinculen sin desperdiciar recursos cargando tanto el tiempo de diseño como el tiempo de diseño. datos ficticios y los enlaces de tiempo de ejecución.

Lo que realmente quiero es la capacidad de tener, por ejemplo, "John", "Paul", "George" y "Ringo" en el diseñador XAML como elementos con estilo en mi ItemsControl, pero que se muestren datos reales cuando la aplicación carreras.

También sé que Blend permite algunos atributos sofisticados que definen datos de enlace de tiempo de diseño que WPF ignora de manera efectiva en condiciones de tiempo de ejecución.

Entonces mis preguntas son:

1. ¿Cómo puedo aprovechar los enlaces en tiempo de diseño de las colecciones y los datos no triviales en el diseñador XAML de Visual Studio y luego cambiar a los enlaces en tiempo de ejecución sin problemas?

2. ¿Cómo han resuelto otros este problema de datos de tiempo de diseño frente a tiempo de ejecución? En mi caso, no puedo usar fácilmente los mismos datos para ambos (como podría hacerlo con, digamos, una consulta de base de datos).

3. ¿Son sus alternativas a la combinación de expresiones que podría usar para el diseño XAML integrado en datos? (Sé que hay algunas alternativas, pero quiero específicamente algo que pueda usar y ver datos de muestra vinculados, etc.)

Con VS2010 puede usar atributos de tiempo de diseño (funciona tanto para SL como para WPF). Por lo general, tengo una fuente de datos simulada de todos modos, por lo que es solo una cuestión de:

• Agregar la declaración del espacio de nombres

  xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

• Agregar el contexto de datos simulados a los recursos de control / ventana

  <UserControl.Resources>
    <ViewModels:MockXViewModel x:Key="DesignViewModel"/>
  </UserControl.Resources>

• Configuración del contexto de datos en tiempo de diseño

  <Grid d:DataContext="{Binding Source={StaticResource DesignViewModel}}" ...

Funciona bastante bien.

Como una amalgama de la respuesta aceptada de Goran y el excelente comentario de Rene.

• Agregue la declaración del espacio de nombres. xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

• Haga referencia a su contexto de datos de tiempo de diseño desde el código.
  <Grid d:DataContext="{d:DesignInstance Type=ViewModels:MockXViewModel, IsDesignTimeCreatable=True}" ...

Karl Shifflett describe un enfoque que debería funcionar igualmente bien para VS2008 y VS2010:

Visualización de datos de tiempo de diseño en Visual Studio 2008 Cider Designer en proyectos de WPF y Silverlight

Laurent Bugnion tiene un enfoque similar que se centra en Expression Blend. Se podría trabajar para VS2010, pero no han confirmado todavía.

Simular datos en modo de diseño en Microsoft Expression Blend

Quizás las nuevas funciones de tiempo de diseño de Visual Studio 2010 y Expression Blend 4 sean una opción para usted.

Cómo funciona se muestra en la aplicación de muestra BookLibrary de WPF Application Framework (WAF) . Descargue la versión .NET4.

Utilizo este enfoque para generar datos de tiempo de diseño con .NET 4.5 y Visual Studio 2013.

Solo tengo un ViewModel. El modelo de vista tiene una propiedad IsInDesignModeque dice si el modo de diseño está activo o no (ver clase ViewModelBase). Luego, puede configurar sus datos de tiempo de diseño (como llenar un control de elementos) en el constructor de modelos de vista.

Además, no cargaría datos reales en el constructor de modelos de vista, esto puede generar problemas en tiempo de ejecución, pero la configuración de datos para el tiempo de diseño no debería ser un problema.

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

Usando Visual Studio 2017, he estado tratando de seguir todas las guías y preguntas como esta y todavía me enfrentaba a una <ItemsControl>que simplemente no ejecutó el código que tenía dentro del constructor de una DesignFooViewModelque hereda FooViewModel. Confirmé la parte "no se ejecutó" siguiendo esta guía "práctica" de MSDN (spoiler: MessageBoxdepuración). Si bien esto no está directamente relacionado con la pregunta original, espero que les ahorre mucho tiempo a otros.

Resulta que no estaba haciendo nada malo. El problema era que mi aplicación debía estar construida para x64. Como Visual Studio todavía es en 2018 un proceso de 32 bits y aparentemente no puede hacer girar un proceso de host de 64 bits para la parte del diseñador, no puede usar mis clases x64. Lo realmente malo es que no hay errores en ningún registro que se me ocurra.

Entonces, si se encuentra con esta pregunta porque está viendo datos falsos en su modelo de vista de tiempo de diseño (por ejemplo: <TextBlock Text="{Binding Name}"/>aparece Namesin importar que establezca la propiedad), es probable que la causa sea su compilación x64. Si no puede cambiar su configuración de compilación a anycpu o x86 debido a dependencias, considere la posibilidad de crear un nuevo proyecto que sea completamente anycpu y no tenga las dependencias (o ninguna dependencia). Por lo tanto, termina dividiendo la mayoría o todas las partes del código, excepto las de inicialización, de su proyecto "Aplicación WPF" en un proyecto de "biblioteca de clases C #".

Para la base de código en la que estoy trabajando, creo que esto forzará una separación saludable de preocupaciones a costa de cierta duplicación de código, lo que probablemente sea algo positivo.

Similar a la respuesta mejor calificada, pero mejor en mi opinión: puede crear una propiedad estática para devolver una instancia de datos de diseño y hacer referencia a ella directamente desde XAML así:

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

Esto evita la necesidad de usar UserControl.Resources. Su propiedad estática puede funcionar como una fábrica que le permite construir tipos de datos no triviales; por ejemplo, si no tiene un ctor predeterminado, puede llamar a una fábrica o contenedor aquí para inyectar en las dependencias apropiadas.