刚刚有了一个可能有用的想法。听起来导体是分层的,所以:
使用事件聚合器触发一个简单的消息类型,其属性包含要激活的视图模型
public class BreadcrumbNavigate
{
public IScreen Screen { get; private set; }
public BreadcrumbNavigate(IScreen screen) { Screen = screen; }
}
指挥应该都在听这些类型的消息;当他们收到一条消息时,他们应该只在当前处于活动状态时才对其进行响应,这意味着只有面包屑路径的叶节点才会响应第一条消息。
如果消息中的虚拟机不是导体的子节点,导体应该关闭自己并重新发布聚合器消息,以便下一个活动导体可以处理它(不确定这将如何工作,因为它取决于导体关闭本身然后传播消息,但就像我说的,这只是一个想法)。
最终,树上某处的正确指挥者将处理消息,并且该指挥者将有一个与消息匹配的子 VM - 这是导航目标,也是消息传播停止的地方
编辑:
由于导体在有活跃的孩子时也很活跃,因此上述方法不起作用 - 所以废弃它!
您可以发布有关您的设置的更多信息吗?
就您所描述的而言,这听起来像是一个简单的面包屑导航场景;为了沿着面包屑返回,您只需TryClose()
在要跳回的 VM 的活动项目上使用:
// on the VM that you want to navigate to...
public void NavigateToMe()
{
// Check if we have a child, if so try and close it...will close all children etc
if (ActiveItem != null)
{
ActiveItem.TryClose();
}
}
显然,您可以将其包装在辅助方法中,例如
public void NavigateTo(IConductActiveItem vm)
{
var iClose = vm.ActiveItem as IClose;
if(iClose != null)
{
iClose.TryClose();
}
}
因此,面包屑中所需的只是对 VM 的引用,检查它是否有一个可关闭的子节点并调用TryClose()
所有子虚拟机/导体应在所选子节点下方关闭 - 显然,这只有在虚拟机的子节点始终是项目指挥
这是假设您只是使用以下对象图:
导体 -> 导体 -> 导体 -> 导体