据我了解,当我们使用 MVP 时,我们会将所有表示逻辑移至 Presenter。但是我们不想让 Presenter 知道视图的实现,那么我们如何才能导航到应用程序中的另一个屏幕呢?您如何管理实际应用程序上的应用程序流?
4 回答
使用一些导航器界面,例如:
interface INavigator
{
void MoveTo (string screenName);
void MoveTo (string screenName, NavigationParameters parameters);
}
然后,每个演示者都会在构造函数中传递此导航器的实例。通过这种方式,导航与演示者和各个视图都分离。
您可以在配置中定义屏幕名称和实际表单类之间的映射。
我假设您的意思是另一个具有自己的 MVP 对的屏幕?
我今天早上在考虑那个案例,我的解决方案可能是有一个 Coordinator 知道 Presenter 和需要打开的 MVP 对。那个会打开新的演示者+视图,完成后,可以选择在第一个演示者上调用一个方法并获得结果。
这样一来,第一个 MVP 不必知道任何关于新屏幕的信息,他们只需触发一个事件。打开第二个窗口并返回通信的逻辑完全包含在协调器中。
这是视图上的方法。因此,您将拥有一个抽象方法,例如 ShowCustomerForm(),WinForms 的实现将是 CustomerForm.Show(或 WinForms 中的任何内容),而在 WebForms 中它将是 Response.Redirct(CustomerForm.aspx)。
我们使用 Lennaert 所谓的协调器(我们称之为工作流控制器)来完成此操作。我来自 Java Web 开发,这个想法是 ApplicactionController 的一种形式。我遇到了一些问题,工作流控制器运行一个命令。每个命令代表一个工作流或一系列相关步骤(因此命名为 workflowcontroller)。flowcontroller 处理命令之间的导航,flowcontroller 具有在步骤之间导航的导航器。每个步骤都有一个完成事件(演示者被连接到该事件)和我们用来导航到下一步的 NextStep 方法。我们的 worflowcontroller 与菜单紧密耦合,因此我们可以在不同的工作流之间导航。这些步骤建立了视图和演示者之间的链接。我们不 没有任何配置,并且已经将建立下一步执行的逻辑硬连接到称为 NextStep 的方法中。它正在生产中,但我对此不太满意。太多的细节在这里进入。我考虑过转向更受事件驱动的东西。我们使用消息总线进行所有其他通信,我想转向使用它在屏幕之间导航。我不知道这是否有帮助。我们的屏幕大部分由顺序工作流程组成。我想改用它在屏幕之间导航。我不知道这是否有帮助。我们的屏幕大部分由顺序工作流程组成。我想改用它在屏幕之间导航。我不知道这是否有帮助。我们的屏幕大部分由顺序工作流程组成。