Каким образом привязка данных в WPF является улучшением по сравнению с предыдущими структурами?

Question

Что принципиально изменилось в структуре привязки данных WPF по сравнению с предыдущими структурами привязки данных?

Я подчеркиваю термин принципиально , то есть АРХИТЕКТУРА, а не ТЕХНИКА.Конечно, это приносит улучшение, но меня больше интересуют эволюционность, ремонтопригодность и масштабируемость и АГНОСТИЧНОСТЬ (ПОРТАТИВНОСТЬ) таких платформ, то есть я на уровне PARADIM.

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

Answer 1

Исходя из мира Windows Forms, я обнаружил следующие преимущества привязки данных WPF:

1. DataContext и привязки Path sопределяется отдельно , и привязка ищет его DataContext в иерархическом порядке (со своими родителями), если он не указан один на себе.

   Преимущество этого можно увидеть, например:с ListView с и DataTemplate с;первый может указывать источник данных (DataContext), а второй определяет, как будут отображаться свойства элементов источника (заданные с помощью Path).

   (Кстати, с этим есть одна возможная проблема, кстати).: AFAIK, в XAML нет способа убедиться, что во время компиляции и DataContext, и Path ссылаются на объект одного типа.)

2. Path s может быть более сложным , чем просто имя свойства.Это, вероятно, наиболее полезно при привязке к XML (можно указать выражение XPath для ссылки на данные), а не при привязке к POCO.

3. В WPF, похоже, нет некоторыхдосадных проблем с привязкой данных Windows Forms:

   • См. мой предыдущий вопрос Winforms привязывают данные к бизнес-объектам в многопоточном сценарии без InvokeRequired? - IIRC, все еще требуется некоторая работа для получения обновлений из фоновых потоков правильно (через Dispatcher) даже с WPF, но из того, что я видел, дела обстоят лучше, чем сWinforms.Я помню, как был пример, показанный в видео Джейсона Долингера о паттерне MVVM . ( Отредактировано : В этом отношении на самом деле ничего не изменилось с тех пор, как Winforms. BeginInvoke был просто заменен классом Dispatcher, что делает вещи несколько приятнее на поверхности, но по сути это все те же механизмы. )

   • Связывание данных Winforms: Может ли TypeConverter использоваться вместо событий Format / Parse? - преобразование значения , выполняемое привязкой, проще, чем с помощью Winforms, поскольку преобразователи значений могут быть указаны непосредственно в XAML;в Winforms вы можете выполнять преобразование значений только через события Format / Parse, которые определены в самой привязке;вы не можете указать конвертер значений непосредственно в конструкторе Windows Forms.Поэтому вам нужно установить привязку в вашем коде;Это означает, что вам нужно обратиться к элементу управления пользовательского интерфейса по имени;что по крайней мере частично нарушает разделение View и Presenter (если вы пытаетесь работать с шаблоном MVP).Не хорошо.

4. Команды не существовали в Winforms.Вместо команд вам приходилось работать с событиями и обработчиками событий в коде (например, saveButton_Clicked).Теперь, если вы хотите делегировать всю логику классу Presenter (опять же, в настройке MVP), вам придется вручную перенаправлять события, такие как нажатие кнопки, из вашего View в Presenter.В WPF привязка данных дополняется наличием ICommand / RoutedCommand, что значительно упрощает этот процесс.