Caliburn + Xamarin навигация

Question

фон:

Мы используем Caliburn.Micro 3.0.0-beta2 с/Android проектом WPF + Xamarin IOS, и мы хотим, чтобы гарантировать, что вид модель может быть кросс-платформенной для повторного использования как можно больше кода.

Мы изучали, как отвлечь нашу навигацию от проверяемой, кросс-платформенной и так называемой модели просмотра, а не взглядов.

Мне было интересно, есть ли у кого-нибудь предложения о том, как мы должны обрабатывать навигацию к приложениям. Наши экраны требуют, чтобы мы вводили некоторые данные, такие как идентификаторы базы данных, в экраны, когда мы перемещаемся. В настоящее время мы сделали это с первого взгляда вида, введя данные в представление и передав его в модель представления, но это не кажется идеальным, поскольку оно действительно должно входить в модель представления, поскольку это логика представления (справа ?).

Модель вида создана для просмотра вида с использованием ViewModelLocator.LocateForView(this);, и тогда это удовлетворяет остальным нашим зависимостям, используя SimpleContainer.

Мы понимаем, что навигация не была внедрена в 3.0.0, но согласно https://github.com/Caliburn-Micro/Caliburn.Micro/issues/142. Мы действительно ищем способ навигации, который может быть похож на решение Caliburn.Micro, которое будет реализовано в ближайшее время, с обнадеживающим взглядом, чтобы внести свой вклад в это, если это возможно.

Вопросы:

1. Как бы мы идти о получении данных в модели представления, а не зрения, чтобы сделать его проще тестировать и больше похоже на то, как наш WPF приложения нужно будет работать?
2. Является ли это даже разумным для мобильного приложения или мы должны придерживаться первого подхода? Если да, то каков был бы проверяемый подход для этого?

Answer 1

Если у вас нет настройки Caliburn.Micro для подхода первого взгляда (можно сделать выборку для этого), структура почти полностью открывается вначале по своей природе. Вначале мне очень трудно работать. Большинство моих «экранов» разрабатываются вокруг рассматриваемой модели. Имея это в виду, я также иногда имею несколько видов для каждой модели просмотра в зависимости от операции (например, добавление/редактирование/детали/список).

1) DI, обычно через репозиторий или другой контекст этого характера, а затем с помощью BindableColllection удерживать и уведомлять об изменениях в представлении. В значительной степени то же, что и WPF. Совсем недавно мой код стал кросс-платформой (WP to WPF, теперь более универсальной), чтобы уменьшить мои головные боли. Большинство используемых шаблонов - это DI (SimpleContainer), репозиторий (EF 6x), Pub/Sub (IEventAggregator). Единственное исключение - Репозиторий, но в той мере, в которой я все еще использую его в WP, но поскольку я использую Sqlite, до недавнего времени EF не могло быть и речи (EF 7 на помощь) ...

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