Статическая проверка привязок - PullRequest
11 голосов
/ 04 сентября 2010

Или " как сделать так, чтобы все ваши привязки оставались правильными? "
(это довольно долго, но потерпите меня, я пытался сделать его настолько коротким, насколько смог)

Рассмотрим следующий пример:

    <TextBox Name="tb" />
    <TextBlock Text="{Binding Text.TheProp, ElementName=tb}" />

Во время компиляции совершенно точно известно, что привязка неверна (т. Е. Синтаксический анализатор знает тип элемента tb, иследовательно, он знает тип своего свойства Text и, следовательно, знает, что TheProp не существует).
Тем не менее, этот код будет компилироваться и выполняться (хотя с сообщением об ошибке привязки в выводе отладки).

Это поведение может оказаться очень полезным в некоторых ситуациях: независимо от того, какого типа мои данные, если они имеют соответствующие имена, у меня все в порядке.Таким образом, мы получаем своего рода «декларативную типизацию утки».

Однако , типизация утки - не всегда хорошая вещь.
В частности, при использовании шаблона MVVM я знаю (большинствовремени) точные типы всех моих объектов ViewModel.С другой стороны, модели со временем становятся все более и более сложными, что заставляет меня беспокоиться о будущем рефакторинге: что, если я решу переименовать некоторые свойства или, не дай Бог, поместить их в отдельный агрегированный объект?Что будет потом со всеми моими привязками?Придется ли мне вручную разгребать все файлы XAML?И даже без рефакторинга - что если я просто сделаю опечатку?

Подобная проблема уже решена в других местах XAML.Например, если вы указали неверное имя свойства в Style/Setter/@Property, вы получите ошибку времени компиляции.
TemplateBinding также обеспечивает такую ​​проверку.Что очень удобно.

Так что в идеале я хотел бы увидеть что-то вроде этого:

ProductViewModel.cs:

    public class ProductViewModel
    {
        public Name { get; set; }
        public Price { get; set; }
    }

ProductView.XAML:

    <UserControl x:Class="Shopping.View.ProductView"
                 x:DataContextType="vm:ProductViewModel"
                 xmlns:vm="clr-namespace:Shopping.ViewModel"
                 ... >
        <TextBox Text="{Binding Name}" />  <!-- OK -->
        <TextBox Text="{Binding Price}" /> <!-- OK -->
        <TextBox Text="{Binding ABC}" />   <!-- Compile time error: there is no property ABC in ProductViewModel -->
    </UserControl>

ShoppingCart.XAML:

    <UserControl x:Class="Shopping.View.ShoppingCartView"
                 x:DataContextType="vm:ShoppingCartViewModel"
                 xmlns:vm="clr-namespace:Shopping.ViewModel"
                 ... >
        <ItemsControl ItemsSource="{Binding Products}"
                      ItemType="vm:ProductViewModel" >  <!-- Static check happens here 
                                                             ShoppingCartViewModel.Products must 
                                                             implement IEnumerable<ProductViewModel> -->
            <ItemsControl.ItemTemplate>
                <DataTemplate DataType="vm:ProductViewModel">
                    <view:ProductView /> <!-- DataContext is known to be of correct type
                                              because of DataTemplate.DataType property -->
                </DataTemplate>
            </ItemsControl.ItemTemplate>
        </ItemsControl>
    </UserControl>

Но вернемся к реальности.На самом деле все эти сновидения просто не произойдут в ближайшем будущем.

Однако я уверен, что я не первый, у кого возникла эта проблема.
Итак, наконец, вопрос в том,: Как убедиться, что ваши привязки верны?И что они остаются такими?

Ответы [ 2 ]

8 голосов
/ 09 сентября 2010

Как насчет статического анализа вашего Xaml, выполняемого как шаг после сборки?

В рамках .Net 4 Microsoft выпустила новую библиотеку System.Xaml для обеспечения надежного анализа Xaml.и поддержка сериализации, независимая от WPF.Теперь они начинают создавать всевозможные интересные вещи, некоторые из которых могут вам помочь.

Например, в XamlToolkit вы найдете XamlDOM , что позволяет легко выполнять статический анализ файлов Xaml.И, если пойти немного дальше, есть правила FxCop для XAML .

. Наибольший интерес представляет BindingFinder * 1016 Роба Рельеа, который имеет явную цель проверки привязок типов в Xaml.Для этого необходимо, чтобы в вашем Xaml были подсказки типа, например атрибут DataType в DataTemplate или новый атрибут d: DataContext в ваших представлениях (который Blend использует для предоставления design-данные времени).Затем он использует XamlDOM для проверки того, что все совпадает.

Обновление: Resharper 6 теперь предоставляет intellisense для привязок данных и предупреждения, еслиВы неправильно указали путь к своей собственности.

2 голосов
/ 05 сентября 2010

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

Другая причина, по которой у меня нет этой проблемы, заключается в том, что я не занимаюсь разработкой модели представления.независимо от Expression Blend.Для всех, кроме самых простых пользовательских интерфейсов, я строю свои модели представлений, используя какое-то внедрение зависимостей, чтобы я мог создать тестовый источник данных, который можно использовать в Expression Blend.Когда я создаю привязки в Blend, я сразу же узнаю, правильно ли я это сделал.

Как и в случае с MVVM, делать это - невероятная боль в заднице, пока вы не поймете, что делаетеи почему.( Это длинное сообщение в блоге от Jonas Follesø дает довольно хороший обзор того, как использовать Ninject для этой цели, хотя нет никаких других рамок, которые вы можете использовать.) ЯЯ уверен, что есть проблемы, которые я еще не обнаружил с помощью этой методологии - помимо проблемы, которую я добавил, добавив DI-фреймворки и Expression Blend к куче вещей, которые мне нужно понять для разработки приложений WPF.

Пабло Казальс сказал, что постоянные эксперименты держат художника молодым.Я не чувствую себя 1011 молодым. 1013

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...