Уведомление об изменении свойств класса разного типа

Всем приветы!
Как говорится - о чем долго хотели спросить, но стеснялись (шутка)

В общем, суть в следующем: есть некий класс А, назовем его источником данных, и некий класс Б - соотв. приемник этих данных.
Данные различного типа, будь то string, double... или вообще составные, типа структур или классов.
Для того, чтобы класс Б определил что именно сейчас изменилось в классе А, я использую такой подход:
в классе А объявлены публичные поля этих типов (данные) и некоторый делегат со строковым (string) аргументом. Когда некоторое поле данных изменилось, я делаю Invoke с "названием" параметра, а класс Б, получивший это название теперь "знает" какое поле из класса А дернуть для обновления уже своей модели...

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

Общий принцип мне понятен, и конечно, со временем я могу самостоятельно разобраться с этим, но если у кого есть какие идеи/примеры/где почитать по этому поводу (серьезные источники, не Метанит!) - буду признателен.

0

Сообщение от HF В чём смысл "приёмника"?

Приемник (часть Model'и) получает данные от источника и прокидывает их уже в свою ViewModel.

Сообщение от HF Это копия класса источника?

Нет. Это свойство (группа свойств), куда попадают значения из источника.

Сообщение от HF И это значит, что отправитель уже знает о получателе

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

Сообщение от HF Можно использовать внутри или снаружи ссылку на этот "источник"

В источнике есть публичный тип, который доступен извне, ну что логично: приемник должен же знать данные какого типа будут приходить (от куда их брать).
А вот наоборот нельзя: в источнике ссылка на приемник не нужна.

Добавлено через 8 минут

Сообщение от HF Внимательно посмотрел и только сейчас заметил

Сообщение от HF И зачем тут события если уже есть зависимость типов

Этот код был для наглядности демонстрации получения имени свойства, в данном случае через string делегата.
Когда шло обсуждение INPC nameof() VS delegate xxx (string yyy).

0

Сообщение от Uswer При всём уважении, но ваши слова мимо, т.к. коллекция Properties создаётся при сборке самого объекта без перебора.

При всём уважении.. это было не лично вам. Ещё раз повторю - если вам что-то задело в моих словах, не воспринимайте так близко. Это был разбор кода, а не вашей личности. Если я ошибаюсь в коде - значит я ошибаюсь в фактах. Но вы начали прям отнекиваться от темы и написанного. Боитесь участвовать в диспутах?

Ведь коллекция создаётся? А чем если не перебором? Код не видел, но скорее всего рефлексией по полям класса.

Добавлено через 2 минуты

Сообщение от wizard41 Этот код был для наглядности демонстрации получения имени свойства, в данном случае через string делегата. Когда шло обсуждение INPC nameof() VS delegate xxx (string yyy).

Но этот пример далёк от реальности? Если да, то стоит всё же привести более близкий пример.
Мой вариант к этому коду какие имеет недостатки для вашего решения?

Сообщение от wizard41 В источнике есть публичный тип, который доступен извне, ну что логично: приемник должен же знать данные какого типа будут приходить (от куда их брать). А вот наоборот нельзя: в источнике ссылка на приемник не нужна.

А что тогда делает SourceClass в TargetClass?

0

Сообщение от HF Но этот пример далёк от реальности?

Не совсем. Но этот подход необходимо изменить.

Сообщение от HF Мой вариант к этому коду какие имеет недостатки для вашего решения?

в Source ничего изменить извне нельзя! Можем только получить (get).

Сообщение от HF А что тогда делает SourceClass в TargetClass?

Говорю же - для демонстрации. В настоящем проекте вытащен только тип (пока их несколько, но скоро будет один, но составной).

Не будем торопить коней, я пока на стадии выбора - как и что применить, чтоб поближе к теме было.

0

Uswer,

По сути, всё то, что написал Wolfdp, уже сделано MS и чтобы это использовать надо просто реализовать INPC в отправителе.

Можно пример? Без иронии, я просто не особо понимаю какой механизм реализации именно у слушателя. Мы же вроде не к UI элементу подвязываем, а своей модели.

0

Сообщение от HF Но вы начали прям отнекиваться от темы и написанного.

Э-э-э! В данной теме я отметился впервые и сразу нарвался на критику с вашей стороны по отношению к коду, поэтому я слегка в ступоре. Ещё раз отмечу, что не я автор темы.

Сообщение от HF Ведь коллекция создаётся? А чем если не перебором?

Да создаётся. Нет не перебором, там что-то типа того:
Где далее по коду в методе SetObject при необходимости расширяется Properties (это происходит при построении объекта в момент установки свойства) и в него помещается значение value.

Добавлено через 4 минуты

Сообщение от Wolfdp Без иронии, я просто не особо понимаю

Да да, я немного ошибся. Беру свои слова назад. Просто сразу не совсем было понятно на каком уровне взаимодействие. Я всё осознал после:

Сообщение от wizard41 Приемник (часть Model'и) получает данные от источника и прокидывает их уже в свою ViewModel.

0

Сообщение от wizard41 в Source ничего изменить извне нельзя! Можем только получить (get).

Это же тоже было демо Ну уберите сеттер. Теперь норм?
То что вы уже объект там держите - уже подразумевает что вы с ним можете всё что угодно сделать.

Добавлено через 5 минут

Сообщение от Uswer Да создаётся. Нет не перебором, там что-то типа того: C# 1 Properties.

/ДушнотаОн
Госпиди, я просто занудствую, а вы видимо не поняли на что именно я акцентирую внимание.
Вот она коллекция. И я сказал - что если нет "перебора" тут, то значит просто уже кто-то сделал это ранее.
И я лично "давлю" на то что задача "хочу свойство обновить из события" обрастает всякими рефлексиями и сложным кодом. И для меня уже само наличие такой коллекции означает что под это действие уже были выделены ресурсы и код занимался подготовкой для этого. А раз решение должно быть простым (а это моё первичное отношение к цели), то такие коллекции - симптом сложного решения. Щас понятно?
/ДушнотаОфф

1

Сообщение от wizard41 в Source ничего изменить извне нельзя! Можем только получить (get).

Если у нас есть просто источник данных, а не модель данных -- стоит таки просто написать MQ с соответствующими сообщениями, паблишарами и подписчиками. Попытка через единый ивент тут скорее всего будет не самое лучшее решение.

1

Сообщение от HF Это же тоже было демо Ну уберите сеттер. Теперь норм? То что вы уже объект там держите - уже подразумевает что вы с ним можете всё что угодно сделать.

HF, ну мы реально о разных вещах говорим... И потом, с чего вдруг надо кого-то скрывать? Ведь он (источник) для того и существует, чтобы из него брать что нужно. Сами данные он формирует и заполняет свои свойства сам - туда никто вмешаться не может. Суть вопроса вообще не в этом. Это мы куда-то отъехали не в ту сторону...

Если нужно в приемнике обновить некоторое свойство, которое изменилось в источнике, то необходимо:
1. издать сигнал (event) о том что произошло изменение;
2. извлечь то свойство, которое поменялось;
3. изменить сопоставленное ему свойство в получателе.

И это да, это не UI элемент, где механизм Binding-а "сам все разруливает". Тут приходится самому (выискивать) менять именно то, что пришло - причем не важно каким путем: будь то INPC, либо Action либо руками созданный делегат.
Ситуацию усугубляет тот факт, что обновить весь тип целиком (что легко) нельзя, т.к. это затрет (перезапишет) другие свойства, которые в данный момент трогать не нужно.

0

0

Сообщение от Wolfdp Попытка через единый ивент тут скорее всего будет не самое лучшее решение

Да, я тоже пришел к этому пониманию.

Добавлено через 9 минут

0