Вставить общие функциональные возможности ViewModel в базовый класс? - PullRequest
1 голос
/ 16 ноября 2009

Я использую MVVM с Призмой и Silverlight. У меня есть несколько разных взглядов на одну модель. Поскольку я пишу больше представлений, их ViewModels, кажется, дублируют много общего кода, связанного с обработкой этой одной модели. Вместо того, чтобы повторять один и тот же общий код на всех виртуальных машинах, я испытываю желание отодвинуть его обратно в модель (что, вероятно, слишком смешало бы проблемы). Или, может быть, в какой-то общий базовый класс ViewModel? Или, может быть, моей виртуальной машине нужен второй уровень «общей виртуальной машины» между ними и моделью? Этот единый общий экземпляр, 2-й уровень-ВМ, консолидирует поведение и состояние, совместно используемые несколькими обычными ВМ.

Есть ли какие-либо комментарии по поводу этих проблем и возможных подходов?


Спасибо за комментарии, ребята. Возможно, мне следовало бы рассказать вам больше о конкретном «разделяемом» коде виртуальной машины.

Я вижу размещение некоторого будущего кода в базовом классе виртуальной машины, но определенный «общий» код, на который я смотрю, кажется, принадлежит INotifyPropertyChanged, реализованному моделью сам. Это частично основано на этом другом потоке .

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

Есть какие-нибудь комментарии по этому поводу?

Ответы [ 4 ]

1 голос
/ 16 ноября 2009

Если общий код может использоваться совместно all ViewModels, то его стоит поместить в базовый тип ViewModel.

Если общий код используется только ViewModel, которые взаимодействуют с конкретной моделью, тогда «совместно используемая» ViewModel - это путь.

0 голосов
/ 17 ноября 2009

В SoapBox Core , который полностью MVVM, я определил интерфейс IViewModel и базовый класс AbstractViewModel, который, как сказал Найджел, просто реализует INotifyPropertyChanged. (Обратите внимание, что SoapBox Core - это WPF, а не Silverlight, но в этом случае это не имеет большого значения. Я также проделал аналогичную работу с Silverlight.)

Затем я определил больше интерфейсов (например, IMenuItem), которые наследуются от IViewModel, и более абстрактные классы, которые обеспечивают базовую реализацию этих интерфейсов.

Теперь, это учитывает все дерево ViewModel, но, как вы сказали, есть также дерево моделей. Я провел почти год, работая с MVVM, и вот мое большое прозрение: не пишите модель. Если вы создаете приложение с нуля, просто поместите все в ViewModel, иначе вы в конечном итоге продублируете тонну кода.

Единственный случай, когда я беспокоился о модели, был, когда я использовал стороннюю библиотеку, которая не реализовала INotifyPropertyChanged и поэтому не была легко связана с. Я полагаю, что автоматически сгенерированный код для структур сущностей также может попасть сюда, но я заметил, что некоторые структуры сущностей теперь дают вам возможность реализовать INotifyPropertyChanged в самих сущностях.

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

0 голосов
/ 17 ноября 2009

Большинство «базовых классов ViewModel» в различных средах MVVM, как правило, содержат поддержку INotifyPropertyChanged и, как правило, некоторую поддержку отправки обратно в поток пользовательского интерфейса.

Кроме того, я думаю, что если у вас есть несколько моделей ViewModel, которые разделяют функциональность, которая должна быть в базовом классе, чем больше я использую этот шаблон, тем больше я обнаруживаю, что использую довольно поверхностную иерархию ViewModels, базовую ViewModel для кода общий для всех моделей представлений и, как правило, другой базовый класс для общих функций в этой области пользовательского интерфейса. Обычно общие команды или где пользовательский интерфейс делится элементами.

ViewModelBase -> ProductsViewModelBase -> NewProductViewModel

0 голосов
/ 16 ноября 2009

Я успешно использовал наследование для ViewModels в New York Times Silverlight Kit , чтобы уменьшить объем реплицируемого кода. Посмотрите на CommunityRecentComments и его родительский класс CommunityBase для примера.

...