MVVM и окно настроек

Всем хорошего дня.

В общем вникая в WPF и MVVM у меня начало подгорать то самое место. А всё из-за чего? Есть главное окно приложения и его VM1, в какой-то момент пользователь может вызвать окно настроек (локальные настройки рабочего места). Следовательно из VM1 порождается окно настроек, которое порождает свою VM2. VM2 должна изменить "модель настроек", которая, в свою очередь, должна повлиять на модель, с которой работает VM1 Таким образом на старте работы VM1 "модель настроек" уже должна существовать! Либо сама "модель настроек" должна рожать VM1/VM2 чтобы те могли подписаться на события "модели настроек". В общем не понятно что должно быть первым курица или яйцо. Кто кого должен создавать?

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

0

Сообщение от wizard41 Вариант 4. Использование MessageBus (шина сообщений).

По сути это MQ (думаю он более знаком людям). И у этого подхода одна радикальная проблема -- нельзя нормально делать GET (в этой конструкции оно и не заложено). Обычно реализуют через таски ожидающие прилёта сообщений, который запросто могут повиснуть.

И я шатал трубу использовать этот подход как "универсальный". Вводиться сообщения "подключись по IP". У тебя изначально один модуль который куда-то там подключается. Потом модулей становится два~много, и уже нужно править сообщение "такой-то подключись по IP", потому что шина одна, слушают её все и нужно вдуплять кому это сообщение адресовано. И это ещё скромный вариант, порой сыпется 100500 сообщений, а тебе нужно одно конкретное.

В подходе DI или даже когда тупо прокидываешь ссылки ты просто выделяешь конкретный скоп и существующий внутренний код не нужно трогать.

Шину сообщений стоит использовать только в случаях когда у тебя есть логика подразумевающая отправку команд без ответа с разных источников разным приемникам (причём очень часто эти участники ещё и динамически появляются и отпадают). Ну или есть паттерны аля CQRS + events_sourcing, но там очередь -- только часть общего комбайна, read идет не через неё.

Сообщение от wizard41 Вариант 2. Наличие публичного события "Обновления" в самом объекте Настроек.

Не особо понял задум. event решают вопрос "рассылки" и не более. Я отнёс это к п.1 т.к. нам всё равно нужно прокидывать объект, который будет знать об это ивенте (хотя прокинуть можно и через DI)

Сообщение от wizard41 Вариант 6. Использование "гибридов".

Стоит избегать, но когда юзаешь либы -- никуда не денешься. Пусть лучше подход будет не очень, но однотипный, а не "каждый пишет как он дышит". Хотя на практике проекты очень часто в это состояние и скатываются. Плак.

--------

В общем случае я бы использовал варианты 1 или 3. По варианту 5 ничего не подскажу (ибо не знаю). От варианта 4 я бы отпирался всеми силами (разве что CQRS + events_sourcing, и то если проект располагает к этому).

ТСу я бы рекомендовал начать с варианта 1.

0

Сообщение от Wolfdp По сути это MQ (думаю он более знаком людям).

Согласен. Но он не знаком ТСу! Поэтому я не стал давать отсылки на него, дабы не "затуманить" и так не очень ясное сознание.

Сообщение от Wolfdp Обычно реализуют через таски ожидающие прилёта сообщений, который запросто могут повиснуть.

"Волков бояться - в лес не ходить" Некий намек на ваш ник
Есть такое дело. Но опять же, все упирается в реализацию. MessageBus нельзя обойти стороной в данном случае. Мы думаем, прежде всего, про "меж-оконный" обмен и настройки, как частный случай этого обмена. ТСу от него не уйти, если он на самом деле будет продвигаться по этой теме.

Сообщение от Wolfdp Не особо понял задум. event решают вопрос "рассылки" и не более.

Когда объект Настройки синглтон. У него может быть евент, который можно дернуть. Причем этот объект не обязательно прокидывать из чего-либо. Да, этот вариант можно спокойно совместить и с п.1 и с DI. Просто посчитал нужным отдельного упоминания про это способ.

Сообщение от Wolfdp Стоит избегать, но когда юзаешь либы -- никуда не денешься.

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

Сообщение от Wolfdp но однотипный, а не "каждый пишет как он дышит"

Тоже верно. Но здесь именно тот случай, когда ТС пишет сам для себя (вернее, он единственный автор своего творения). Поэтому и выбор стиля только за ним одним.

Сообщение от Wolfdp я бы использовал варианты 1 или 3.

Аналогичное мнение. Вар 3 я сразу предложил, чтобы не "мучаться"... ))

0

Сообщение от wizard41 Согласен. Но он не знаком ТСу!

Без обид, но почему Вы всегда огульно делаете выводы о знаниях других? (не только в отношении меня кстати)

Мало того, что я знаю что такое Очередь Сообщений, так я даже использовал её, правда всего в одном проекте. В моём текущем проекте её конечно можно прикрутить, но главный вопрос был не в механизме доставки сообщений об изменении настроек, а в том, что "модель настроек" должна появиться на уровне приложения, а не при создании какого-то представления или его VM, и все модели представления должны получать её изменения и читать нужные им настройки. В целом вопрос темы считаю для себя решённым. Используя DI "модель настроек" будет передаваться всем заинтересованным объектам.
Все, кто принимал участие в обсуждении, большие молодцы. Всем спасибо!

0

0