Вот пример сценария, нацеленного на разработку MVVM WPF / SL:
- Просмотр привязок данных для просмотра модели Свойство "Цель"
- "Цель«выставляет поле объекта с именем« data », которое существует в локальной модели приложения, и называется« Original »
- , когда« Original »изменяется, оно должно вызывать уведомление для модели представления изатем распространите это уведомление об изменении в View.
Вот решения, которые я придумала, но мне не все из них нравятся.Я ищу другие идеи, и к тому времени, когда мы придумаем что-то невероятное, я уверен, что Microsoft выпустит .NET 5 с расширениями WPF / SL для улучшения инструментов для разработки MVVM.
На данный момент вопрос звучит так: «Что вы сделали для решения этой проблемы и как она сработала для вас?»
Вариант 1.
Предложение:
Присоединить обработчик к событию PropertyChanged data , которое отслеживает строковые значения свойств, которые его интересуют, которые могли измениться, и вызывает соответствующее уведомление.
Почему мне это не нравится:
Изменения не всплывают естественным образом, объекты должны явно наблюдаться, если данные переходят на новый источник, события должны быть отключены-регистрация / регистрация.
Почему мне это нравится:
Я получаю явный контроль над распространением изменений, и мне не нужно использовать какие-либо типы, которыепринадлежат на более высоком уровне приложения, такие как собственно зависимостьсвязи.
Вариант 2.
Предложение:
Присоединить обработчик к data sСобытие PropertyChanged, которое повторно вызывает событие во всех свойствах, используя имя свойства name.
Почему мне это не нравится:
По сути, это то же самое, что и option1, но менее разумно и вынуждает меня никогда не менять имена своих свойств, поскольку они должны совпадать с именами свойств в data
Почему мне это нравится:
Это очень легко настроить, и мне не нужно об этом думать ... Опять же, если я пытаюсь думать и меняю имена на вещи, которые имеют смысл, я стреляю в себяногу, и тогда я должен думать об этом!
Вариант 3.
Предложение:
Наследовать мой взглядмодель из объекта зависимости и напрямую уведомлять источники привязки об изменениях.
Почему мне это не нравится:
Я даже на 100% не уверен в свойствах зависимости /оbjects может сделать это, это была просто мысль, чтобы разобраться.Также я лично не чувствую, что типы WPF / SL, такие как Dep Obj, принадлежат на уровне модели представления.
Почему мне это нравится:
ЕСЛИ оно имеетвозможность, которую я ищу, это хороший ответ!минус эта досадная проблема с наслоениями.
Вариант 4.
Предложение:
Используйте постоянную систему обмена сообщениями агента, основанную наЗадайте Parallels DataFlow Library, чтобы распространить все через связанную конвейерную обработку.
Почему мне это не нравится:
Я никогда не пробовал это, и почему-то я думаю, что это будетбыть лишенным, плюс это требует, чтобы я думал о своем коде совершенно по-разному.
Почему мне это нравится:
У него есть возможность разрешитьмне сделать ОЧЕНЬ забавные манипуляции с моделью данных на основе push и использованием ActionBlocks в качестве проверочных и установочных параметров, чтобы затем в частном порядке изменить свойства модели представления и явно контролировать уведомления PropertyChanged.