Свойства WPF на интерфейсе модели представления?

Question

Использование "ванильного" WPF (без фреймворка MVVM, как Prism).

Позвольте мне сказать заранее, что я абсолютно поддерживаю кодирование против абстракций / интерфейсов против реализаций, когда это возможно.

В WPF, когда вы делаете свои привязки в представлении, вы на самом деле не кодируете свои привязки к интерфейсу viewmodel. Вы действительно связываетесь с реализацией viewmodel / datacontext. Я думаю, что вы могли бы даже утверждать, что вы привязываетесь к пустому холсту, так как представление не знает, с чем оно будет связано во время выполнения.

Так есть ли интерфейс модели представления, который включает каждое свойство, которое представление будет связывать с бесполезной абстракцией? Должны ли интерфейсы просмотра модели быть более простыми и содержать только методы, необходимые для изменения состояния (или обработки команд и т. Д.).

Я надеюсь, что этот вопрос имеет смысл. :)

Answer 1

ИМХО, ViewModel - это модель для представления. В 90% случаев они, скорее всего, будут 1 к 1 ... полезная часть возвращает логику в нечто более тестируемое, чем XAML. Вместе они составляют пользовательский интерфейс, но его поведение отделено от представления пользовательского интерфейса.

Лично я не использую интерфейсы ViewModel. Я не думаю, что между шаблоном команд и свободным связыванием, которое используют WPF и Silverlight, будет полезна абстракция.

Я мог бы использовать интерфейсы ViewModel в системе, где поведение и состояние View сильно различались в зависимости от некоторых бизнес-критериев. Например. если ваш View выполнял редактирование поля водительских прав и требуемые поля менялись от штата к штату, вы могли бы использовать один сложный вид, связанный с интерфейсом IStateDriversLicenseViewModel. Правильным может быть внедрение зависимостей в зависимости от состояния, с которым вы работаете, и предоставление таких свойств, как IsOrganDonorSectionVisible, чтобы представление могло отражать правильные изменения. Однако в этом случае я подозреваю, что представление, состоящее из пользовательских элементов управления, приведет к меньшему количеству проблем и меньшей сложности в обслуживании.

Answer 2

Абстракция [т.е. программирование интерфейса] полезна тогда и только тогда, когда требуется слабая связь [т.е. независимая от реализации взаимосвязь между потребителем и производителем].

В зависимости от вашей интерпретации модели View ViewModel [MVVM] допускается жесткая связь.

На практике типичный сценарий, который я видел, - это тесная связь между View и ViewModel и между View и Model (s). Как правило, поскольку представления разработаны с учетом конкретных бизнес-требований, модели ViewModel адаптированы к представлению, чтобы облегчить его бизнес-роль.

Как Бен Фон Хандорф предлагает , та часть нашего приложения, которая фактически адаптирует базовую модель (ы) к ViewModel, должна быть отделена от нашего представления [по крайней мере, декларативное представление часть]. Таким образом, адаптация обычно фиксируется реализацией Команды представления. Таким образом, в то время как декларативный аспект представления не имеет представления о базовой модели (ях) и слабо связан, бизнес-реализация или команда представления вводит тесную связь между представлением и моделью. Опять же, это круто, потому что единственная цель View - использовать эти данные определенным образом в рамках своей деятельности.

Я тоже являюсь поклонником абстракций, в частности, программирования интерфейса, внедрения зависимостей [DI] и инверсии управления [IoC]. Однако, когда тесная связь имеет смысл, как это имеет место в MVVM, тогда абстракция является чрезмерным осложнением.

IMO, простота, представленная тесной связью, делает MVVM настолько привлекательной по сравнению с его кузенами в пространстве Model View Controller [MVC].

Answer 3

Я думаю, что вообще не имеет смысла определять интерфейс, когда вы собираетесь создать только один класс, который его реализует. Это описывает каждый класс модели представления, который я когда-либо создавал. И представление не может использовать интерфейсы в любом случае.

I do иногда использует интерфейсы в классах модели представления, но только если мне нужно определить взаимодействия между теми классами, которые должным образом не живут в модели.