У меня есть две основные мысли по этому поводу, но YMMV.
Во-первых, я бы переместил специфичный для реализации код из виртуальной машины в «сервис», который по сути является просто классом, который выполняет эту работу. Это может быть, например, класс customerService, в котором есть реализация методов сохранения, удаления, обновления, а реализация RelayCommand будет вызывать службу для выполнения действия и обновлять любые свойства представления соответствующим образом.
Примером может быть то, что RelayCommand может установить значение свойства «ShowProgressBar», которое связано с видимостью индикатора выполнения. Затем он вызвал бы функцию сохранения в сервисе, а по завершении (это должно быть асинхронно, между прочим) должен снова обновить «ShowProgressBar». Таким образом, ViewModel контролирует состояние View независимо от логики основного приложения.
Во-вторых, я бы посмотрел на используемую вами базовую модель представления и постарался максимально упростить ее, добавляя только компоненты, общие для всех ваших моделей представления. Затем вы можете создать другие модели базовых представлений или интерфейсы в зависимости от ситуации. Например, вы можете решить, что все ваши модели представлений будут предоставлять свойство ShowProgressBar, которое может быть связано с индикатором выполнения на вашей странице, или вы можете создать ProgressViewModelBase или IAllowProgress, которые вы унаследуете / внедрите на страницах, для которых требуются индикаторы выполнения.
В самом представлении должно быть как можно меньше кода, вы должны стремиться к нулю кода (хотя, к сожалению, есть вещи, которые можно сделать только в коде).
Одна вещь, которую я обнаружил, к моему ущербу, заключается в том, что создание сложных моделей представления может быть дорогостоящим с точки зрения производительности, особенно если вы регистрируете команды relay и источники / слушатели агрегатора событий, поэтому поддержание базовой модели представления очень полезно для нас. Это особенно важно, если вы используете ViewModelCollections для отображения списков объектов Model, и когда создание ViewModel происходит в потоке пользовательского интерфейса (что, вероятно, если ViewModel создается при создании представления).