Я тут прочитал, что, чтобы модель информировала представление о своём изменении, то надо реализовать интерфейс INotifyPropertyChanged. А чтобы наоборот - представление известило о своём изменении модель - ничего делать не надо? Этакая односторонняя обязанность?

Ну, просто если привязка двунаправленная, то почему с одной стороны надо чего-то реализовывать, а с другой - нет?

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




И всё работает.

Далее, я посмотрел сюда http://msdn.microsoft.com/en-us/library/ms752347(v=vs.100).aspx
авторNote that to detect source changes (applicable to OneWay and TwoWay bindings), the source must implement a suitable property change notification mechanism such as INotifyPropertyChanged.
Затем сюда http://msdn.microsoft.com/ru-ru/magazine/dd419663.aspx
авторИнтерфейс INotifyPropertyChanged содержит событие под названием PropertyChanged. Если у свойства объекта модели представления есть новое значение, она может создать событие PropertyChanged для уведомления системы привязки WPF о новом значении. После получения этого уведомления система привязки опрашивает свойство, и привязанное свойство какого-то элемента пользовательского интерфейса получит новое значение.
Затем сказал и глянул пример Джоша Смита по вышеупомянутой статье, где у него код буквально следующий (такой же и в статье)


Этот код вообще в себе ничего не содержит, кроме костыля для проверки наличия свойства с таким именем (лечится рефлексией и лямбда-выражениями) и собственно вызова события изменения свойства. Причём событие, судя по всему, предназначено для системы привязки, ибо никаких подписчиков на это событие в коде программы у него не обнаружено.

Получается, что если модель представления не может измениться кроме как через представление, то смысла в этом интерфейсе (INotifyPropertyChanged) нет. Т. е. если это не какое-нибудь многопоточное приложение, у которого модель может поменять клиент, работающий одновременно с другими клиентами, то этот интерфейс не нужен?



Далее, теперь представим, что то, что написано - правда. Тогда события развиваются таким образом:

1. Я изменяю значение в представлеии.
2. Через привязку, пройдя кучу валидаций, модель представления получает новое значение.
3. В модели представления возникает событие изменение свойства.
4. Модель представления извещает представление, что у неё изменилось свойство.
5. Представление меняет своё свойство в соответствии с новым свойством модели представления.

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


И снова вопрос - зачем нужен этот интерфейс? В каких сценариях, кроме многопоточности, модель представления может поменяться не через представление, а как-то по-другому, что потребует ДЕЙСТВИТЕЛЬНОГО обновления представления?

авторВы заметили, что вся эта фигня не нужна, начиная с пункта 2?
Не с п. 2, а с того момента, как модель представления создаёт событие изменения своего свойства.

авторИ снова вопрос - зачем нужен этот интерфейс? В каких сценариях, кроме многопоточности, модель представления может поменяться не через представление, а как-то по-другому, что потребует ДЕЙСТВИТЕЛЬНОГО обновления представления?
Ладно, надо ещё учесть, что модель представления может поменяться не только из-за изменения представления, но и из-за изменения значения в самой модели. Тогда опять сталкиваемся с многопоточностью и прочими штуками. Но тогда и между моделью (М) и моделью представления (МП) должен быть двунаправленный механизм оповещения об изменении свойств. Вот только в приведённой статье и примере кода ничего такого нет - всё однонаправлено. Значения в М меняются через МП у него вот так:


Т. е. никакого другого способа изменить М нет. А значит, в однопоточном режиме работы такой программы надобность в интерфейсе INotifyPropertyChanged отсутствует, так? Более того, он даже вреден - лишние вычисления и в без того тормозном ВПФе, которому даже аппаратное ускорение не даёт превзойти ВинФормс.

Но вот про применимость этой штуки только в многопоточном приложении нигде-то как раз и не сказано. Более того, в самом примере кода и намёка на многопоточность нет.

Т. е. если бездумно передрать этот код и потом у себя его реализовывать, то кто-то посторонний может недоумённо спросить - "А зачем тебе ЭТО? Оно же тут не работает.".

Выше в коде _customer - это объект модели.

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


1.

Теперь другой глупый вопрос (не буду новые темы создавать - пусть будет моя тема глупых вопросов). Читаю раздел "Validation Process" (там много пунктов про валидацию). А именно
авторBefore the binding engine runs the ValidationRule objects at any given step, it removes any ValidationError that was added to the Validation.Errors attached property of the bound element during that step.
Там же пример кода для отображения ошибки:


Меня интересует часть


Получается, что всегда возможно отобразить только первую ошибку, т. к. второй в коллекции ошибок просто не может появиться по алгоритму валидации, описанному по ссылке? Не зря же тот же Джош Смит в коде отображения ошибки использует немного другой синтаксис:


?


2.

Читаю тут http://msdn.microsoft.com/en-us/library/bb613546(v=vs.100).aspx, в разделе "How Data Binding References are Resolved", что быстрее всего байндится к "DependencyProperty of a DependencyObject". Вы часто делаете свои модели представления DependencyObject с DependencyProperties, чтобы получить 20-30 дополнительных % производительсности, или забиваете?


3.

В той же статье

авторBind IList to ItemsControl not IEnumerable

If you have a choice between binding an IList<T> or an IEnumerable to an ItemsControl object, choose the IList<T> object. Binding IEnumerable to an ItemsControl forces WPF to create a wrapper IList<T> object, which means your performance is impacted by the unnecessary overhead of a second object.
Т. е. если я перед привязкой преобразую свою коллекцию к списку через расширяющий метод ToList(), то это будет всё равно что оставить его без всяких приведений - всё равно ВПФ этот же метод и вызывает фактически? Т. е. лучше изначально все коллекции в модели представления делать IList?

Вот вы как делаете?

авторТ. е. лучше изначально все коллекции в модели представления делать IList?
Ну, т. е. те, которые байндятся к ItemsControl.

SeVauser7320пропущено...

Ну, т. е. те, которые байндятся к ItemsControl.

Красавцы, только после таких пенок помалкивайте в тряпочку о тормознутости wpf.
Если коллекция для редактирования не поддерживате INotifyCollectionChanged, то wpf сам реализует этот интерфейс, что увеличивает накладные расходы по памяти в два раза и дает соответствующие тормоза
У ВПФ тормознутость в отрисовке - т. е. в том, как внутри он взаимодействует с ДХ.

SeVauser7320пропущено...

Ну, т. е. те, которые байндятся к ItemsControl.

Красавцы, только после таких пенок помалкивайте в тряпочку о тормознутости wpf.
Если коллекция для редактирования не поддерживате INotifyCollectionChanged, то wpf сам реализует этот интерфейс, что увеличивает накладные расходы по памяти в два раза и дает соответствующие тормоза
"Реализация интерфейса" подразумевает создание полной копии коллеции? Т. е. когда я на IEnumerable вызываю расширяющий метод ToList, то я на самом деле создаю новую копию коллекции, а не создаю List, который внутри у себя ссылается на тот же массив, что и коллекция, реализующая IEnumerable? Чего ж они не догадались сделать такую оптимизацию?