Шаблоны и архитектуры могут быть трудны для понимания, когда люди действительно думают, как правильно реализовать их.
Это всего лишь рекомендации. Они дают вам разделение обязанностей, и вы, как разработчик, решаете, как применять их в зависимости от вашей проблемы. Выполнять их одним способом может быть сложнее, чем делать их другим способом, и это почти все.
У паттерна нет способа решить все проблемы, которые у вас будут.
Из практики выяснилось, что в большинстве случаев View лучше общаться с одним ViewModel. Мой опыт доказал, что это действительно делает вашу логику более чистой, так как изменение пары ViewModel может сломать один View, а отладка и отслеживание происходящего может быть труднее. Если вам нужно разделить какое-то состояние и / или логику между Views, которая принадлежит одному ViewModel, подумайте, как вы можете иметь два ViewModels вместо одного, и добавьте Model, чтобы разделить это состояние и логику, и ViewModels поделитесь этим объектом.
A ViewModel может связываться с несколькими Views (в то время как каждый View имеет одну ViewModel). Большую часть времени, если вы можете сделать один ViewModel для связи с одним View, они это делают. Это облегчает жизнь.
Для сложной взаимосвязанной логики иногда бывает сложнее иметь один ViewModel на View. Обычно вы делите ваш ViewModel на иерархию, где у вас будет один ParentViewModel и пара меньших, более мелких, ChildViewModels. Но этим ChildViewModels, возможно, придется общаться со своими родителями или между собой. Разбивая ViewModels на иерархии, вы можете получить единый ViewModel для View, но если вы не можете не принуждать себя. Иногда проще этого не делать.
По крайней мере, не пытайтесь получить один ViewModel для View. Используйте итеративный подход и рефакторинг. Сделайте один больший ViewModel и подключите его к другому Views. Позже проведите рефакторинг вашего пути к разбивке MainViewModel на более мелкие и попытайтесь заставить их общаться с меньшим количеством возможных представлений.
Совместное использование Model между ViewModels - это прекрасно. Я думаю, что Models, вероятно, вещь, которая используется недостаточно. Люди пытаются добавить больше логики к ViewModels, создающему связь между ними, в то время как они должны использовать Models.
Одна важная вещь, о которой вам нужно подумать, - это разделение Презентация и Модель . Поработайте над своей моделью , и вы увидите большие преимущества.
Если в качестве примера у вас должна быть модель Recipe, так как Recipe является вашей DomainModel и должна иметь данные и поведение, связанные с рецептом. Тогда у вас будет RecipeViewModel, и вы будете частью Presentation и будете иметь логику презентаций для Recipe. Тогда у вас будет RecipeView, который будет подключен к RecipeViewModel, который отвечает за фактические графические элементы, представляющие, как Recipe Представлено для пользователь и реагировать и настраивать его виджеты / элементы управления на изменения в RecipeViewModel.
В MVVM Views обычно не связываются с Models. Они общаются с ViewModels, а затем общаются с Models.
Одна большая проблема, которую я вижу, состоит в том, что люди рассматривают Models как то, что они хранят в базе данных, а все остальное (Views, ViewModels, Services и т. Д.) Как приложение. Это большой недостаток. Если вы не читали Домен-управляемый дизайн Я настоятельно рекомендую его, так как он подробно объясняет ценность хорошего Models.
Вот несколько ресурсов: