具有MVP和应用程序控制器模式的会话状态

具有MVP和应用程序控制器模式的会话状态,mvp,session-state,state,Mvp,Session State,State,我已经为开发创建了一个MVP(被动视图)框架,并决定采用应用程序控制器模式来管理视图之间的导航。这是针对WinForms、ASP.NET和WPF接口的 虽然我不是100%相信这些视图技术真的是可交换的,但这是我目前的目标,因此我的MVP框架是相当轻量级的 我正在努力适应的是“业务对话”的概念,它需要(a)在视图的生命周期内维护状态信息,或者更可能的是,(b)在用例的生命周期内跨多个视图维护状态信息(业务对话)。我希望状态管理成为框架的一部分,因为我不希望开发人员担心它。他们所需要做的就是“启动”

我已经为开发创建了一个MVP(被动视图)框架,并决定采用应用程序控制器模式来管理视图之间的导航。这是针对WinForms、ASP.NET和WPF接口的

虽然我不是100%相信这些视图技术真的是可交换的,但这是我目前的目标,因此我的MVP框架是相当轻量级的

我正在努力适应的是“业务对话”的概念,它需要(a)在视图的生命周期内维护状态信息,或者更可能的是,(b)在用例的生命周期内跨多个视图维护状态信息(业务对话)。我希望状态管理成为框架的一部分,因为我不希望开发人员担心它。他们所需要做的就是“启动”一个对话,“注册”对象,框架完成其余工作,直到“结束”一个对话

有人对如何将其融入MVP有什么想法(模式)吗?我想这可能是应用程序控制器职责的一部分(委托给对话管理器对象),因为它知道当前状态,以便将用户发送到下一个视图。。。。但后来我认为,对话的开始和结束可能取决于演示者,因此接下来是演示者来管理对话以及为该对话注册的对象。不幸的是,这意味着不能在不同的对话中使用演示者。。。所以这个想法似乎不正确


正如你所看到的,我不认为有一个简单的答案(我已经寻找了一段时间)。那么其他人有什么想法吗?

如果只涉及用户界面,那么支持业务对话所需的类应该驻留在演示者中。否则,它应该位于模型和控制器中,从视图到演示者再到模型。关于业务对话的信息以另一种方式流动。我怀疑这是一种只存在于演讲者身上的东西

由于所有视图都可以访问演示者,因此您可以构建支持对话的对象,以便在多个视图中维护这些对象

请记住,视图是了解软件中数据的窗口。他们很少显示其他数据,并将用户交互传递回执行逻辑的演示者