Вопрос скорее архитектурный, интересуют принятые практики.
Идеологически MVVM предполагает, что обработкой событий от элементов UI занимается ModelView и ICommand, которые отвязаны от собственно UI, что правильно.
Но возникает одна проблемма — как в этом случае изменить UI, после обработки соответствующей команды? Вешать еще обработчик на Click, исключительно для UI логики или подписывать UI объекты типа Window на обработку событий от MVVM?

IB>Вопрос скорее архитектурный, интересуют принятые практики.
IB>Идеологически MVVM предполагает, что обработкой событий от элементов UI занимается ModelView и ICommand, которые отвязаны от собственно UI, что правильно.
IB>Но возникает одна проблемма — как в этом случае изменить UI, после обработки соответствующей команды? Вешать еще обработчик на Click, исключительно для UI логики или подписывать UI объекты типа Window на обработку событий от MVVM?

UI биндится к свойствам ModelView, при изменении свойств автоматов меняется UI.

Здравствуйте, IB, Вы писали:

IB>Вопрос скорее архитектурный, интересуют принятые практики.
IB>Идеологически MVVM предполагает, что обработкой событий от элементов UI занимается ModelView и ICommand, которые отвязаны от собственно UI, что правильно.
IB>Но возникает одна проблемма — как в этом случае изменить UI, после обработки соответствующей команды? Вешать еще обработчик на Click, исключительно для UI логики или подписывать UI объекты типа Window на обработку событий от MVVM?

Вроде же стандартное решение — биндинг свойств UI элементов к public свойствам ViewModel и генерация события PropertyChanged при изменении значения. Или что понимается под "изменить UI"?

Здравствуйте, IB, Вы писали:

IB>Вопрос скорее архитектурный, интересуют принятые практики.
IB>Идеологически MVVM предполагает, что обработкой событий от элементов UI занимается ModelView и ICommand, которые отвязаны от собственно UI, что правильно.
IB>Но возникает одна проблемма — как в этом случае изменить UI, после обработки соответствующей команды? Вешать еще обработчик на Click, исключительно для UI логики или подписывать UI объекты типа Window на обработку событий от MVVM?
Чаще всего достаточно описанных выше решений: команда меняет свойства, меняется UI.
Если нет свойств: подписываемся на события, которые генерируются где-то в модели.
Еще один подход: attached behavior под конкретный сценарий. В принципе то же самое, что на события подписываться, зато появляется реюзабельность.

Здравствуйте, IB, Вы писали:

IB>Вопрос скорее архитектурный, интересуют принятые практики.
IB>Идеологически MVVM предполагает, что обработкой событий от элементов UI занимается ModelView и ICommand, которые отвязаны от собственно UI, что правильно.
IB>Но возникает одна проблемма — как в этом случае изменить UI, после обработки соответствующей команды? Вешать еще обработчик на Click, исключительно для UI логики или подписывать UI объекты типа Window на обработку событий от MVVM?

Объекты типа Window лучше тоже спрятать за какими-то интерфейсами.

Здравствуйте, IB, Вы писали:

IB>Идеологически MVVM предполагает, что обработкой событий от элементов UI занимается ModelView и ICommand, которые отвязаны от собственно UI, что правильно.

ViewModel.

IB>Но возникает одна проблемма — как в этом случае изменить UI, после обработки соответствующей команды?

Вплоть до смены декораций, если свойство контрола Visible забаиндить на соответствующее свойство модели либо подвесить на него триггер.

Единственный спорный в плане кошерности вопрос на сегодня — это создание новых UI объектов типа окон как результат на реакцию происходящих в модели событый. Один из кошерно-интеллигентских вариантов — создание модели нового окна через фабрику, где вместе с моделью магическим путём создаётся новоё окно. Рабоче-крестьянский способ — не париться и создавать окно (о! ужос!) прямо из модели.

Здравствуйте, IB, Вы писали:

IB>Вопрос скорее архитектурный, интересуют принятые практики.
IB>Идеологически MVVM предполагает, что обработкой событий от элементов UI занимается ModelView и ICommand, которые отвязаны от собственно UI, что правильно.
IB>Но возникает одна проблемма — как в этом случае изменить UI, после обработки соответствующей команды? Вешать еще обработчик на Click, исключительно для UI логики или подписывать UI объекты типа Window на обработку событий от MVVM?

Идеологически в xaml.cs не должно быть ничего.
В общем случае, проблема решается с помощью Behavior<T>, где T, это визуальный элемент к которому behavior атачится, e.g. T = TextBox.
В частном случае (и в большинстве случаев), проблема решается с помощью свойств ViewModel.
При этом никаких обработчиков никуда не вешается и не нарушается принципа отсутствия прямой зависимости между UI и ViewModel.

Т.е. когда не получается забиндиться на свойства ViewModel, приходится делать Behavior.

Здравствуйте, IT, Вы писали:

IT>Единственный спорный в плане кошерности вопрос на сегодня — это создание новых UI объектов типа окон как результат на реакцию происходящих в модели событый.
Вот! Ты знал. )

Здравствуйте, Venom, Вы писали:

V>Идеологически в xaml.cs не должно быть ничего.

Паттерны не должны быть сильнее здравого смысла.
Если например модель поменялась, и вам надо вызвать метод Refresh() какого-то стороннего контрола, карты например, которое не сделать биндингом.
Делать тут специальный behavior имхо глупо, проще передать сообщение.

Здравствуйте, IT, Вы писали:

IT>Единственный спорный в плане кошерности вопрос на сегодня — это создание новых UI объектов типа окон как результат на реакцию происходящих в модели событый. Один из кошерно-интеллигентских вариантов — создание модели нового окна через фабрику, где вместе с моделью магическим путём создаётся новоё окно. Рабоче-крестьянский способ — не париться и создавать окно (о! ужос!) прямо из модели.

Ну, вот вроде феншуйный способ http://stackoverflow.com/a/3388241/1964969
Всё остаётся на уровне View. А инстанс ViewModel будет создаваться через какой-то инжектор/локатор, благо матчинг DataTemplate позволяет добиться этого без проблем:

<DataTemplate DataType="{x:Type MyViewModel}">
    <MyViewOrControl />
</DataTemplate>

Здравствуйте, IB, Вы писали:

IB>Но возникает одна проблемма — как в этом случае изменить UI, после обработки соответствующей команды? Вешать еще обработчик на Click, исключительно для UI логики или подписывать UI объекты типа Window на обработку событий от MVVM?

Оставлю это здесь (украдено отсюда):



Начните с того, что проще, убедитесь, что работает и сделайте рефакторинг. При рефакторинге код из view можно cпрятать в attached behavior, события MVVM (на которые вы хотите подписать view) переделываются в обычные property + binding. Сильно увлекаться не советую, это только для фанатиков (pure MVVM) требуется, чтобы во View не быть кода. Обычным людям достаточно сделать код DRY (повторяемый во View код -> behavior).

Если вы конкретизируете проблему (что именно требуется менять и в каком контроле), то можно будет посоветовать что-то конкретное. В MVVM хватает танцев с бубном (один заковыристее другого) для PasswordBox, multi-selection List controls, и т.д.