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

Question

Я работаю над приложением на основе WPF. Среда - VS2008 SP1 с .NET 3.5 SP 1. В нашей разработке мы широко используем шаблон MVVM.

I.e. разработчики приложений пишут Модели и ViewModels (C#), тогда разработчики пользовательского интерфейса будут писать «Представления» с помощью WPF Binding (XAML). Разработчики приложений также записывают единичные тесты поверх ViewModels. Мы используем методологию непрерывной интеграции, и мы выполняем модульный тест diond при каждой модификации

Проблема заключается в отсутствии процесса или инструментов проверки правильности привязки данных в XAML. Например:

1. App разработчик пишет свойство NmberOfApples и модульные тесты, чтобы проверить его правильное поведение
2. разработчик UI создает пользовательский элемент управления и привязать его к свойству
3. App разработчик считает, что свойство имеет опечатки и исправить свое имя NumberOfApples
4. было бы компиляции ошибки времени в любой C# код использует NmberOfApples собственности, и такие ошибки будут б е легко поймать (Continuous Integration)
5. Связывание данных в XAML файлы не будут проверены, и он будет работать ошибка времени

Мой вопрос будет «Есть ли какой-либо инструмент или методология, которая поможет нам проверить правильность привязки данных в XAML во время компиляции? »

Answer 1

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

Основная идея - создать набор статических (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 свойства класса static, а также потому, что вы ссылаетесь на точное свойство в статическом классе, когда статический класс восстанавливается, ваш xaml не должен компилироваться.

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

EDIT:

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

Answer 2

Существует, пожалуй, неплохие сценарии, где это поведение действительно желательно. В любом случае, по дизайну, ошибки привязки привязаны и являются причиной того, что у вас возникнут проблемы с поиском чего-либо, что поможет вам в этом.

Самое лучшее, что я видел, это обработчик проверки исключений, который будет отображать обязательные ошибки: http://msdn.microsoft.com/en-us/library/system.windows.controls.exceptionvalidationrule.aspx

Аргументом для этого мнения и ViewModels призваны быть развязан до точки, где можно было бы использовать в целях для нескольких ViewModels. Он также помогает в «изгибаемости» представлений, так что теоретически дизайнерские типы могут создавать представление, не запуская кучу ошибок, пока они это делают. Я понимаю, что это может не соответствовать вашему процессу, но это история.

Answer 3

Я согласен с предыдущим ответом. Это «по дизайну», и нет способа проверить его во время компиляции.

Я также нашел боль.

Лучший и единственный способ, который я нашел, - проверить вывод отладки Visual Studio во время выполнения. Любая ошибка привязки будет напечатана, как только вы откроете окно, содержащее ее.

Я согласен, если вы считаете, что это дерьмовый и ненадежный метод, но он должен работать, если у вас нет большого количества окон. Вы можете создать полуформальную тестовую практику, когда время от времени вы открываете любое окно, которое ищет специфические ошибки привязки.

Answer 4

В настоящее время мы используем Caliburn и модульные тесты способом, описанным в этой статье Testing Bindings In WPF.Недостаток этого решения, разработчик пользовательского интерфейса пишет код, который имеет смысл только проверять привязки и может быть опущен, если MS (или кто-то) будет писать компилятор проверки XAML.

Answer 5

Если вы установили ReSharper, одна из функций, которую вы получите, это «проверка кода». Одна из вещей, которые обнаружит этот осмотр, - это случаи, когда ваша привязка не разрешает свойство в контексте данных. Вы можете легко отфильтровать окно «Результаты проверки», чтобы отображать только эти проблемы.

Обратите внимание, что для этого необходимо явно указать тип вашей модели просмотра в ресурсах XAML.

Answer 6

Это было лет с тех пор оригинальный вопрос был задан вопрос и ответил, но, как я только что проверил, решение, возможно, получили проще с тех пор. ReSharper, кажется, предлагает правильный Intellisense без необходимости генерации статических классов, упомянутых в принятом ответе.

Но я не был свидетелем ошибки времени компиляции, как указано в принятом ответе. Я даже пытался использовать [XamlCompilation (XamlCompilationOptions.Compile)] безрезультатно. Пожалуйста, встаньте меня, если я что-то убью.