WPF - это хорошая идея, чтобы сохранить независимость ViewModel от WPF?

Question

В этой теме я действительно хочу узнать, как люди стараются не допускать, чтобы все проблемы WPF были недоступны для ViewModels в WPF.

Приветствия

AWC

Answer 1

Мое личное руководство: Да, если это легко выполнимо. Мне действительно нравится разделение интересов подхода View - ViewModel, но, поскольку я почти уверен, что я ' Я никогда не буду использовать мои ViewModels без WPF, я не буду делать свой код более сложным или менее читаемым, просто чтобы избежать ссылки на WPF.

Answer 2

Я думаю, что это почти всегда возможно, если вы не против написать немного больше кода. :)

Подумайте о вещах, которые вы могли бы как-то представить на стороне ViewModel:

1. Управление - ПЛОХАЯ идея по бесчисленным причинам.
2. Кисти - могут быть легко перемещены к выходам преобразователя, статическим ресурсам и шаблонам.
3. Перечислите такие значения, как Visibility и т. Д. - опять же, конвертеры - ваши друзья здесь; bool для видимости, X для видимости и т. д.
4. Обработчики событий - они становятся ICommands в «новом мире»
5. Диспетчер: Это то, что я иногда "обманываю", но я чувствую себя грязным каждый раз, когда делаю. :)

Не знаю, может быть, я просто пурист, но если я вижу какие-либо "использующие System.Windows" или "использующие System.Windows.Controls" в верхней части моей модели представления, я знаю, что взяли легкий выход из того, что, вероятно, вернется и укусит меня в задницу позже.

Answer 3

AWC,

По моему опыту, это лучшая практика , чтобы не оставлять все проблемы WPF вне ViewModel . Я не говорю о классах, специфичных для View (списки, textBlocks и т. Д.), Но мы всегда должны помнить, что управление доступом к потоку пользовательского интерфейса является важной частью WPF и должно поддерживаться внутри ViewModel. Это связано с тем, что представление отвечает только за предоставление четкого шаблона для представления данных, предоставляемых виртуальной машиной. Именно ViewModel решает, должны ли данные извлекаться асинхронно и при каких обстоятельствах они должны быть связаны - выше подразумевается использование Dispatcher, который управляет доступом к потоку пользовательского интерфейса. Итак, мой ответ: не забывайте, что WPF - это не только класс View.

Полагаю, вы хотели спросить, не должны ли разработчики беспокоиться о View в классах VM. Если я прав, ответ да , они не должны беспокоиться. ViewModel - это просто слой, предоставляющий полный набор данных / команд анонимному докладчику (View) - ему все равно, какая часть предоставленных данных будет использоваться связанными представлениями, и ни как эти данные будут представлены.

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

Answer 4

Я не согласен - не является ли смысл ViewModel обрабатывать несоответствие импеданса между представлением и моделью? Я не думаю, что вам нужно сохранять ViewModel на 100% свободным от WPF - виртуальная машина готова помочь вам .

Answer 5

Я всегда обнаруживал, что одна из самых полезных вещей, которые ViewModel делает для меня, - это маршалировать доступ к объекту в потоке Dispatcher, чтобы сохранить все эти неловкие ошибки о том, что «к этому объекту можно получить доступ только из потока UI». Я бы сказал, что это противоречит тому, чтобы быть независимым от WPF, так что это не универсальное правило, что вы должны стремиться быть агностиком. Конечно, не очень хорошая идея, чтобы ваша ViewModel содержала коллекции, например. ListBoxItems или что-нибудь в этом роде. Разделение - это хорошо, но вы должны пойти на некоторые уступки потребностям технологии.