Хорошо, значит, MemberListViewModel
для страницы списка, а MemberEditViewModel
- страница редактирования.
В моей модели я бы выставил следующие классы:
ListMembersTask
EditMemberTask
Вы внедряете их во все репозитории, которые нужны каждому, и они раскрывают свойства и методы, необходимые для какой-то абстрактной вещи, выполняющей каждую задачу. Например, ListMembersTask
может иметь метод с именем CreateMember()
, который возвращает новый EditMemberTask
, инициализированный с пустым объектом Member.
Ваш ViewModel
затем вводится с соответствующей задачей (таким образом, MemberListViewModel
вводится с ListMembersTask
и т. Д.). Ваш MemberListViewModel
будет иметь RelayCommand
, который будет вызывать CreateMember()
, и взять возвращенный EditMemberTask
, ввести его в MemberEditViewModel
и передать новый MemberEditViewModel
докладчику.
Если вы следуете такому подходу, то хранилища отвечают только за постоянство. Задача оборачивает состояние бизнес-логики во время сеанса, а модель представления просто делает задачу привязываемой.
Следующий шаг, над которым я работал, - это обойтись без специфичных для Задачи моделей представления, и теперь я передаю необработанное задание Презентатору, который проверяет объект и строит иерархию модели представления для задачи из элементарных элементов модели представления (например, EditTextViewModel
, ChooseOneViewModel
, DockingLayoutViewModel
и т. д.).