Как разработать гибкую навигационную логику в проекте MVVM?

Question

Я разрабатываю проект с использованием шаблона MVVM, поэтому используются WPF, привязка и т. Д.

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

Например, есть горизонтальная полоса сверху как навигация 1-го уровня, затем вертикальный элемент управления Accordion слева как 2-й и 3-й уровеньнавигация и некоторые элементы CollapsiblePanels в главной области как навигация 4-го уровня.

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

Наши требования, ребята, сохраняютоб изменении представлений о том, как часть бизнес-логики (воспринимайте ее как пользовательский элемент управления) должна находиться на 1-м, 2-м, 3-м или 4-м уровне: вчера UserControlA может находиться внутри CollapsiblePanel, поэтому это навигация 4-го уровня;сегодня он может быть повышен до элемента 2-го уровня по запросу некоторых пользователей.

Я не буду винить инженеров по требованиям, поскольку в проекте MVVM можно будет разработать деликатную навигационную структуру, чтобыизменение графического интерфейса легко или даже настраивается.

Есть предложения?Примеры кода приветствуются!

Answer 1

Вы должны взглянуть на Prism в сочетании с MEF или Unity. Вместе они позволяют писать модульные приложения, которые звучат именно то, что вы ищете. В основном то, что вы будете делать, это

• создавать автономные элементы управления, которые ничего не знают ни друг о друге, ни о том, где они находятся в макете. Вы создаете UserControlA, UserControlB и т. Д. И соответствующие им модели представления.
• обмениваться данными между виртуальными машинами, используя EventAggregator / Mediator по выбору. Они передаются виртуальным машинам с помощью внедрения зависимостей (это то, что делают MEF / Unity)
• Вы создаете основной макет, который не содержит каких-либо конкретных элементов управления, только пустые пространства, называемые регионами. Они идентифицированы по имени.
• затем, в одной точке где-нибудь в коде, xaml или даже файле конфигурации, вы связываете все вместе, говоря «регион с именем A нуждается в элементе управления типа UserControlA». Теперь, если требование меняется, вы просто измените эту строку, чтобы UserControlA перешел в область AA. Больше ничего в приложении не меняется.

Требуется некоторое изучение, чтобы привыкнуть к нему, но в конце концов оно того стоит. С тех пор, как я начал использовать Prism, я никогда не оглядывался назад.