我正在开发基于WPF的MVVM应用程序,并且在我的应用程序中有关于处理视图导航的最佳方式的问题。具体来说,当我有多个可能导致导航的视图时,我感兴趣的是最简洁的方法来实现此导航。
让我总结一下我当前的应用程序布局,以便我可以更好地解释这个问题。
上图显示了我的主shell的粗略布局。主导航区域是静态的,并提供许多按钮。存在主要应用程序功能的按钮,例如状态,配置,诊断等。当按下其中一个按钮时,将设置上下文导航区域的内容。具体而言,这通过使上下文导航区域包含内容控件来实现,其中Content
属性绑定到类型ViewModelBase
的单个属性。此外,视图模型和视图与应用程序资源中的数据模板绑定在一起。
在上下文导航内容控件中填充的特定视图/视图模型随后提供与在主导航中选择的主要功能相关的附加导航选项。在上下文导航中选择选项后,主内容区域的更新方式与先前使用上下文导航所描述的方式完全相同。
所以我想你可以描述MainNavigation
和ContextualNavigation
区域的组合,它们与Outlook Style菜单栏非常相似。即底部的主要选择,顶部的次要选择,导致主要内容区域的变化。
现在问题。我可以做这个工作,但它开始变得非常混乱!我已经导致MainNavigationViewModel
导致导航,并且多个上下文ViewModels
会被填充到导致导航的ContextualNavigation
区域。在某些情况下,主要内容区域中的动作也可能也产生导航需求。我实际上还有一个Ribbon控件,也可能导致一些导航。所以我在ViewModels
遍布各处都有导航,而且我不相信它是可维护的。 PS。如果您想知道,我目前正在使用信使系统来允许视图模型之间的分离通信。
我开始认为最好的方法是创建一个抽象服务,负责我的应用程序中所有视图模型的导航,但不确定它会是什么样子。我是否在这里是正确的,如果有的话,是否有人对应用程序范围的导航服务有任何建议,处理来自多个视图模型的导航?
答案 0 :(得分:0)
首先,您使用的MVVM方法是什么?首先查看或查看模型?
正确的选择可以让你的生活更轻松。
你已经有了正确方向的想法接口和继承 - 抽象导航层。
如果您已经使用Messanger,它实际上遵循类似的方法。 在你的情况下,架构计划将是不必要的,花时间把它拉下来。