Кому нужно создавать экземпляры модели просмотра в MvvmCross

Question

Просто для того, чтобы все было ясно: я знаю, что MvvmCross очень гибко описывает, где и как можно создавать модели представлений. Мой вопрос скорее о правильном разделении проблем, упрощении проектирования сложных кросс-платформенных приложений.

У нас есть приложение со списком клиентов и информацией о клиенте. На iPad и Surface список и данные отображаются на одной странице, но на более мелких устройствах список клиентов и детали для выбранного клиента разделяются между отдельными страницами. Итак, у нас есть PCL с CustomerListViewModel и CustomerDetailsViewModel. Теперь, как мы должны управлять временем жизни модели просмотра изнутри переносимой библиотеки классов?

Первоначально я сделал это с помощью кода в реализации CustomerListViewModel, который выглядит следующим образом:

public ICommand SelectCustomerCommand 
{ 
    get { return new MvxCommand(SelectCustomer); } 
} 

public void SelectCustomer() 
{ 
    if (formFactor == FormFactor.Phone) 
    { 
     ShowViewModel<CustomerDetailsViewModel>(new CustomerDetailsViewModel.NavObject(this.SelectedCustomer)); 
    } 
    else 
    { 
     this.CustomerDetails = new CustomerDetailsViewModel(this.SelectedCustomer); 
    } 
} 

Что важно здесь то, что мы либо уравнять ShowViewModel, что в свою очередь просит выступающему построить объект CustomerDetailsViewModel и вынести его в новую страницу или явно создать экземпляр CustomerDetailsViewModel и связать его с CustomerDetails.

После просмотра эпизодов 32 и 42 видеороликов N + 1 MvvmCross я не уверен, что это правильный способ сделать это. Конечно, это работает, но должна ли модель просмотра заботиться о деталях создания экземпляра другой модели представления?

Моя вторая мысль была реорганизовать этот код и поместить эту логику в качестве ведущего, так что я могу просто написать в реализации CustomerListViewModel:

public void SelectCustomer() 
{ 
    ShowViewModel<CustomerDetailsViewModel>(new CustomerDetailsViewModel.NavObject(this.SelectedCustomer)); 
} 

... и ведущий будет делать все остальное внутри кода, вызванного Вызов ShowViewModel. Тем не менее, в эпизоде ​​42 он показал, как контролировать жизнь вид модели прямо с соответствующей точки зрения:

protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e) 
{ 
    base.OnNavigatedFrom(e); 
    VisibleViewModel.IsVisible(false); 
    if (e.NavigationMode == NavigationMode.Back) 
     KillableViewModel.KillMe(); 
} 

Но если пожизненный вид модели управляется ведущий, мы не должны пытаться поставить KillMe вызов внутри презентующего логика? Я знаю, что небольшая часть кода не имеет большого значения, но не может ли это быть преимуществом, чтобы поместить ее в класс ведущего и уменьшить код?

Answer 1

Определенно, ViewModel не должен обрабатывать ничего в отношении вида (экрана).

Одна быстрая идея: у меня есть пользовательский презентатор, который может создавать представления на основе запросов ShowViewModel <>.

Пользовательский докладчик является ответственностью за просмотр, поэтому вы можете проверить ориентацию экрана.

http://slodge.blogspot.co.uk/2013/06/presenter-roundup.html

Answer 2

Во второй части этого вопроса:

Но если пожизненный вид модели управляются ведущим, мы не должны пытаться поместить KillMe вызов внутри логики докладчика? Я знаю, что небольшая часть кода не имеет большого значения, но не может ли это быть преимуществом, чтобы поместить ее в класс ведущего и уменьшить код?

В настоящее время презентация представления модели организована ведущим - она ​​получает ViewModelRequest объектов и решает, что с ними делать.

Однако, как правило, не создают ViewModels - вместо:

• ведущий обычно создает/показывает вид
• затем View создает (или местонахождение) в ViewModel в рамках OnCreate, ViewDidLoad или OnNavigatedTo обработка.

И поэтому я не думаю, что продолжительность жизни модели представления является обычно «под контролем ведущего» - вместо этого я думаю, что ViewModel является «Модель для View» - так это время жизни «контролируется его точки зрения».

Для случаев, когда вам нужна логика shutdown/dispose/killMe в вашей модели ViewModel, если вы хотите переместить эту логику обратно в презентаторе или в какой-то другой объект - тогда вы определенно могли бы это сделать, если бы захотели - это ваше приложение и приложение являются королем.

Однако, в этих случаях я подозреваю, что вам понадобится презентатор, чтобы получить какое-то уведомление из представления - так как часто ведущий не знает, когда демонстрации удаляются (когда модаль отклоняется, когда кнопка «Назад» нажатие, когда Android очищает представления стека для сохранения памяти и т. д.).

Как еще один способ подумать об этом, если ведущий был переименован в INavigationService, то какие роли вы хотите, чтобы INavigationService принадлежал вашему приложению?