Я думаю, стоит упомянуть, что вам не всегда нужны три разных класса для ваших "комбо" MVVM. V всегда будет своим собственным классом, виртуальной машине, вероятно, также понадобится свой собственный класс (хотя я не думаю, что это необходимо), но M может быть одинаковым во всем проекте, если это подходит вашему приложению. Если вы создаете небольшое приложение, скажем, у вас всего 10-15 различных методов обслуживания, вероятно, имеет смысл иметь один единственный класс, отвечающий за вызов вашего веб-сервиса, обработку ошибок и выполнение асинхронных обратных вызовов для различных виртуальных машин. , И если вы создаете действительно маленькое приложение, возможно, имеет смысл иметь только одну ВМ и, скажем, 2-3 вида, которые привязываются к этой единственной ВМ. Возможно, в этом случае вам даже не нужен отдельный класс Model, просто вызовите веб-сервис напрямую из вашей виртуальной машины. В конце концов, вы создадите сервисную ссылку на этот веб-сервис. Сгенерированные прокси-классы будут действовать как ваша Модель.
Я пытаюсь указать, что, читая о MVVM, легко предположить, что для каждого «комбинированного» MVVM всегда будет три физических файла. Это то, что я подумал, когда начал экспериментировать с MVVM, и подумал про себя «Ух ты, это много файлов. И уау, что если у меня есть несколько общих методов в веб-сервисе, которые нужно вызывать несколькими Классы моделей, тогда у меня будет множество дублированного кода повсюду. ". Но когда у меня прояснилась голова, я понял, что мне решать, что лучше всего работает в моем приложении.