Проверьте привязку данных в XAML во время компиляции

Решение вашей проблемы обсуждается в этой статье .

Основная идея состоит в том, чтобы создать набор статических (c #) классов ViewModel MetaData, содержащих строку значение свойств ваших классов ViewModel, которые затем можно использовать в своем xaml. В статье объясняется, как использовать генерацию текста T4 для создания этих статических классов метаданных. Вы можете использовать любой инструмент генерации кода по вашему выбору.

, чтобы ваша виртуальная машина имела следующее:

namespace Mine
{
  public class MyViewModel
  {
    public int MyInt {get;set;}
   public string MyString {get;set;}  
  }
}

И вы создаете код, создавая это:

namespace Mine.MetaData
{
  public static class MyViewModelMetaData
  {
    public const string MyInt = "MyInt";
    public const string MyString = "MyString";
  }
}

, а затем в своем xaml вы добавляете пространство имен в свой xaml и связываете ваши элементы управления для класса метаданных

<TextBox Text="{Binding Path={x:Static Metadata:MyViewModelMetadata.MyInt}}"/>

. Если вы используете надстройку, например resharper , то она предоставит вам intellisense для свойств статического класса, а также потому, что вы ссылаетесь на точное свойство в статическом классе , когда статический класс регенерируется, ваш xaml не должен компилироваться.

Это довольно гладко, я думаю, что это здорово, и у него есть шанс сохранить рассудок большинству людей, но ваш опыт может отличаться. :)

РЕДАКТИРОВАТЬ:

Между прочим, я не верю, что «модели представления тесно связаны с представлениями». На мой взгляд, представления неразрывно связаны со своими моделями представления, но это должно быть только одним способом. ViewModels должен быть полностью независимым от любой реализации представления. Это как ViewModel - это интерфейс, а View - это конкретный реализованный класс. Поэтому по этой причине я не добавляю никаких свойств, специфичных для WPF (например, перечисление видимости), в мою ViewModel, потому что это обязывает меня использовать WPF вечно (что на самом деле неплохо :)), но это ставит под угрозу обслуживание.

Это довольно здорово, я думаю, что это круто, и у него есть шанс сохранить рассудок большинству людей, но ваш опыт может отличаться. :)

РЕДАКТИРОВАТЬ:

Между прочим, я не верю, что «модели представления тесно связаны с представлениями». На мой взгляд, представления неразрывно связаны со своими моделями представления, но это должно быть только одним способом. ViewModels должен быть полностью независимым от любой реализации представления. Это как ViewModel - это интерфейс, а View - это конкретный реализованный класс. Поэтому по этой причине я не добавляю какие-либо специфические для WPF свойства (например, перечисление видимости) в мою ViewModel, потому что это обязывает меня использовать WPF для вечности (что на самом деле неплохо :)), но это ставит под угрозу обслуживание.

Это довольно здорово, я думаю, что это круто, и у него есть шанс сохранить рассудок большинству людей, но ваш опыт может отличаться. :)

РЕДАКТИРОВАТЬ:

Между прочим, я не верю, что «модели представления тесно связаны с представлениями». На мой взгляд, представления неразрывно связаны со своими моделями представления, но это должно быть только одним способом. ViewModels должен быть полностью независимым от любой реализации представления. Как будто ViewModel - это интерфейс, а View - это конкретный реализованный класс. Поэтому по этой причине я не добавляю никаких свойств, специфичных для WPF (например, перечисление видимости), в мою ViewModel, потому что это обязывает меня использовать WPF вечно (что на самом деле неплохо :)), но это ставит под угрозу обслуживание.

но ваш пробег может отличаться. :)

РЕДАКТИРОВАТЬ:

Между прочим, я не верю, что «модели представления тесно связаны с представлениями». На мой взгляд, представления неразрывно связаны со своими моделями представления, но это должно быть только одним способом. ViewModels должен быть полностью независимым от любой реализации представления. Это как ViewModel - это интерфейс, а View - это конкретный реализованный класс. Поэтому по этой причине я не добавляю никаких свойств, специфичных для WPF (например, перечисление видимости), в мою ViewModel, потому что это обязывает меня использовать WPF вечно (что на самом деле неплохо :)), но это ставит под угрозу обслуживание.

но ваш пробег может отличаться. :)

РЕДАКТИРОВАТЬ:

Между прочим, я не верю, что «модели представления тесно связаны с представлениями». На мой взгляд, представления неразрывно связаны со своими моделями представления, но это должно быть только одним способом. ViewModels должен быть полностью независимым от любой реализации представления. Это как ViewModel - это интерфейс, а View - это конкретный реализованный класс. Поэтому по этой причине я не добавляю какие-либо специфические для WPF свойства (например, перечисление видимости) в мою ViewModel, потому что это обязывает меня использовать WPF для вечности (что на самом деле неплохо :)), но это ставит под угрозу обслуживание.

ViewModels должен быть полностью независимым от любой реализации представления. Это как ViewModel - это интерфейс, а View - это конкретный реализованный класс. Поэтому по этой причине я не добавляю какие-либо специфические для WPF свойства (например, перечисление видимости) в мою ViewModel, потому что это обязывает меня использовать WPF для вечности (что на самом деле неплохо :)), но это ставит под угрозу обслуживание.

ViewModels должен быть полностью независимым от любой реализации представления. Это как ViewModel - это интерфейс, а View - это конкретный реализованный класс. Поэтому по этой причине я не добавляю какие-либо специфические для WPF свойства (например, перечисление видимости) в мою ViewModel, потому что это обязывает меня использовать WPF для вечности (что на самом деле неплохо :)), но это ставит под угрозу обслуживание.