моделей от которых можно (и стоит оттолкнуться):
1) Архитектура без разделения контекстов (ДА ВСМ? Ну накой черт тебе по 2 класса на каждую страницу, если страниц 3 штуки).
Решение:
Page.PushAsync()
(Чистая Page=>Page навигация)
2) Архитектура с частичным разделением.
Отличие: Page сама создает себе ViewModel (например BindingContext = new ViewModeType()), умирает так же вместе с ней.
Возможные вариации:
а) Есть некий отдельный класс NavigationService, который как-то понимает что за след страницу ты хочешь получить. Как он это делает не важно. Энумка, Dict<string, type> не важно. Раздупляет как ему навигироваться тоже по-разному. Хоть эвент, хоть через MessageBus.
to be continue...
б) Нет отдельного сервиса навигации, все держится на честном слове и карте переходов. След страница создается на предыдущей. Но существует разграничение ответственности. Вызовы API, расчеты и тд вынесены во ViewModel. 3) Архитектуры с полным разделением. VM => VM. Вся навигация вызывается из ViewModel. Причем переход является на другую VM. Т.к. XF не может такое себе позволить, она даёт App.CurrentMainPage и все. Вот сервис, который оборачивает навигацию вокруг NavPage должен принимать на вход одну VM, и создавать сам другую VM+Page. И ее пушит. Вариаций тут тоже много: а) Как понять какая VM какой Page? IoC контейнер. У Page в конструкторе лежит VM. Вызывается IoC.Resolve(PageType). Ответственность за создание полностью отдана во вне. (Инверсия управления) Сами страницы и VM не могут создавать себе подобных. Можно и без IoC. Просто тогда надо знать ещё и маппинг типов. PageType => VMType. Тогда можно через Activator или рефлексию, например, создать и то и другое.
Обсуждают сегодня