Насколько допускающий повторное использование классы ViewModel должны быть?
Я работаю над приложением WPF, и я структурирую его с помощью шаблона MVVM. Первоначально у меня была идея, что ViewModels должен быть допускающим повторное использование, но теперь я больше не слишком уверен.
- Я должен смочь снова использовать свой ViewModels, если мне нужна схожая функциональность для приложения WinForms?
- Silverlight не поддерживает все вещи, которые делает WPF - я должен смочь снова использовать для приложений Silverlight?
- Что, если я хочу сделать GUI Linux для своего приложения. Затем мне нужен ViewModel для создания в Моно - это что-то, за что я должен бороться?
- И так далее..
Так; нужно записать классы ViewModel с одним определенным Представлением в памяти или думать о возможности многократного использования?
3 ответа
Чтобы ответить на ваш вопрос, подумайте о Принципе единой ответственности:
"У класса должна быть одна, и только одна причина для изменения."
Я бы сказал, что в пределах разумного, вы обычно не хотите повторно использовать ViewModel для нескольких представлений. Основная причина, по которой я утверждаю это, заключается в том, что это даст вашей ViewModel более чем одну причину для изменения. Другими словами, она должна будет меняться при изменении одного или другого представления, а это, на мой взгляд, уже две причины для изменений. На чем это остановится? В этом случае я бы не стал усложнять и связал одну ViewModel с View.
Еще одна вещь, о которой следует подумать при использовании MVVM в WPF, - это шаблонизация данных. Этого гораздо проще добиться, если каждая ViewModel будет обслуживать одно и только одно представление.
В общем, применяйте принцип YAGNI - скорее всего, он вам не понадобится. Если вы не видите, что такие вещи потенциально возможны, я бы придерживался самого простого подхода, чтобы заставить ваше программное обеспечение работать в соответствии с требованиями, которые у вас есть на данный момент.
На мой взгляд, основная цель MVVM - устранить код, который не может быть легко проверен модульными тестами. Поскольку модель представления может быть протестирована, а представление - нет, это достигается тем, что представление делается настолько тупым, насколько это возможно. В идеале, как это можно сделать с помощью XAML, представление полностью декларативно и только привязывает данные к модели представления. Отсюда мантра "никакого кода позади".
Повторное использование модели представления в различных технологиях пользовательского интерфейса на самом деле не является целью MVVM. Если вы попробуете это сделать, у вас, вероятно, возникнет соблазн перенести код, специфичный для технологии пользовательского интерфейса, в представление, чтобы сохранить многоразовость модели представления. Это противоречит главной цели - тестируемости.
Если вы действительно столкнетесь с необходимостью поддержки различных технологий пользовательского интерфейса, то вы все равно можете объединить общую логику моделей представлений в общий "презентационный" слой. Однако я бы не стал этого делать, пока не буду уверен, что это необходимо.