Является ли наследование ViewModel приемлемым в MVVM?

Question

У меня есть сценарий, где есть две страницы для отображения текущих и доставленных заказов.Страницы имеют почти одинаковую привязку и команды, поэтому создание отдельных моделей ViewModel приведет к дублированию кода

Я рекомендовал использовать одну и ту же модель ViewModel для обеих страниц, поскольку они будут представлять одну и ту же модель, только статусы заказов будут отличаться.Данные поступают с разных конечных точек, поэтому у меня есть два метода обслуживания.Мне не нравится идея сделать одну ViewModel для обеих страниц, потому что это заставит меня сказать ViewModel, что он должен получать Orders от одного из методов сервиса при инициализации ViewModel.

Решение, о котором я подумал, состоит в том, чтобы сделать OrdersViewModel в качестве базового класса, где присутствуют все общие члены, и создать два производных класса с именами OrdersInProgressViewModel и DeliveredOrdersViewModel.

My each ViewModelимеет метод InitializeAsync, если я решу пойти с первым подходом и иметь одну ViewModel для обеих страниц, мне, вероятно, придется передать статус в качестве навигационных данных в InitializeAsync и решить, какой метод службы использовать для получения заказов.

При втором подходе я мог бы иметь две отдельные ViewModel и в их InitializeAsync вызывать соответствующий метод службы.

Какой подход будет более придерживаться MVVM?

Мне также нужно сохранитьпомните, что может потребоваться более специфичное поведение страницы (еще один аргумент против единственной ViewModel для обеих страниц)

Answer 1

Я бы предложил вам использовать второй подход, который вы описали. Использование базового класса viewmodel, а затем реализация производных классов.

EDIT

Ответ на похожий вопрос на самом деле очень похож на то, что я имею в виду.

Как правило, я бы порекомендовал вам не иметь наследования между различными классами ViewModel, а вместо этого иметь их наследование напрямую от общего абстрактного базового класса. Это сделано для того, чтобы избежать ненужной сложности, загрязняя интерфейсы классов ViewModel членами, которые находятся на более высоком уровне в иерархии, но не в полной мере соответствуют основной цели класса. Связывание, которое идет с наследованием, также, вероятно, затруднит изменение класса ViewModel, не затрагивая ни один из его производных классов.