具有 MVP 和应用程序控制器模式的会话状态
我创建了一个用于开发的 MVP（被动视图）框架，并决定采用应用程序控制器模式来管理视图之间的导航。这是针对 WinForms、ASP.NET 和 WPF 接口。
尽管我不是 100% 相信这些视图技术真的可以互换，但这就是我目前的目标，因此我的 MVP 框架相当轻量级。
我正在努力适应的是“业务对话”的概念，它需要状态信息（a）在视图的生命周期内维护，或者更可能的是（b）在多个视图的生命周期内维护用例（业务对话）。我希望状态管理成为框架的一部分，因为我不希望开发人员担心它。他们所需要做的就是“开始”对话，“注册”对象，框架会完成其余的工作，直到“结束”对话。
有人对如何将其融入 MVP 有任何想法（模式）吗？我认为它可能是应用程序控制器职责的一部分（委托给对话管理器对象），因为它知道当前状态以便将用户发送到下一个视图......但后来我认为这可能取决于演示者开始和结束对话，然后由演示者管理对话以及为该对话注册的对象。不幸的是，这意味着演示者不能在不同的对话中使用......所以这个想法似乎不正确。
正如您所看到的，我认为没有一个简单的答案（我已经寻找了一段时间）。那么其他人有什么想法吗？
I've created an MVP (passive view) framework for development and decided to go for an Application Controller pattern to manage the navigation between views. This is targeted at WinForms, ASP.NET and WPF interfaces.
Although I'm not 100% convinced that these view technologies really swappable, that's my aim at the moment so my MVP framework is quite lightweight.
What I'm struggling to fit in is the concept of a "Business Conversation" that needs state information to be either (a) maintained for the lifetime of the View or, more likely, (b) maintained across several views for the lifetime of a use case (business conversation). I want state management to be part of the framework as I don't want developers to worry about it. All they need to do is to "start" a conversation, "Register" objects and the framework does the rest until the "end" a conversation.
Has anybody got any thoughts (patterns) to how to fit this into MVP? I was thinking it may be part of the Application Controller responsibility (delegating to a Conversation Manager object) as it knows about current state in order to send the user to the next view.... but then I thought it may be up to the Presenter to start and end the conversation so then it comes down the presenters to manage conversations and the objects registered for the that conversation. Unfortunately that means presenters can't be used in different conversations... so that idea doesn't seem right.
As you can see, I don't think there is an easy answer (and I've looked for a while). So anybody else got any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果仅涉及用户界面，则支持业务对话所需的类应驻留在演示器中。否则它应该在模型和控制器中从视图到演示者再到模型。有关业务对话的信息以相反的方式流动。我怀疑是可以驻留在演示者中的东西。
由于所有视图都可以访问演示者，因此您可以构建支持对话的对象，以便可以在多个视图中维护它们。
请记住，视图是了解软件中数据的窗口。他们几乎不做其他显示数据，而是将用户交互传递回执行逻辑的演示者。
The classes needed to support a Business Conversation should reside in a presenter if it only involves the User Interface. Otherwise it should be in the Model and controller from the View to the Presenter to the Model. With information about Business Conversations flowing the other way. I suspect is something that can reside just in the Presenter.
Since all Views have access to the Presenter you then have the ability to structure the objects supporting the conversation so that they can be maintained across several views.
Remember Views are a window into what data resides in your software. They did little other display data and pass user interactions back into the presenter which does the logic.