控制器在实现 MVP 模式的 gwt 应用程序中应该扮演什么角色?

发布于 2024-09-18 07:27:48 字数 802 浏览 7 评论 0原文

我是 GWT 新手,在长时间的间隙后重新开始编程...我的问题是关于 GWT 中的 MVP 实现,我已经阅读了以下帖子,它们非常有帮助,但我仍然有一些疑问

什么是 MVP 和 MVC,有什么区别? 您对构建 GWT 应用程序有何建议? MVC、MVP 还是自定义消息传递解决方案?

我认为 GWT 教程 ( MVP 的 http://code.google.com/webtoolkit/articles/mvp-architecture.html) 还具有适当的控制器 (AppController),并且某些响应是在控制器级别而不是在呈现器级别进行管理。所以我的问题是 Controller 在 MVP 模式实现中应该扮演什么角色?

我们应该从哪里发起异步服务器调用、演示者或控制器,比如说如果我必须保存记录,我应该从演示者调用服务器函数(调用 DAO 并保存记录)还是演示者应该使用事件总线和控制器发布事件对事件进行操作并调用服务器函数进行保存。

I am new to GWT and getting back to programming after long gap...my question is about MVP implementation in GWT, I have gone through the following post and they were quite helpfull, but i still have some doubts

What are MVP and MVC and what is the difference?
What's your recommendation for architecting GWT applications? MVC, MVP or custom messaging solution?

i think the GWT tutorial (http://code.google.com/webtoolkit/articles/mvp-architecture.html) of MVP also has contoller (AppController ) in place and some of the responses are managed at Contoller level not at presenter. So my question is what should be the role of Controller in MVP pattern implementation?

From where should we initiate the async server call, presenter or controller , say if i have to save the record should i call the server function (which calls the DAO and saves the record) from Presenter or should presenter post event using event bus and conroller act on the event and calls server function for saving.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

梦纸 2024-09-25 07:27:48

链接到的 GWT 教程页面介绍了 AppController:

处理不特定的逻辑
任何演示者,而是驻留在
在应用层,我们将
引入AppController组件。

所以它是多个 Presenter、View 和 Model(可能是多个 Model)之间的粘合剂。它还处理浏览器历史记录。也许还有一些不是某个演示者特有的其他内容。

至于服务器调用:有多种选择,但我个人不会从视图中执行,也不会从演示者中执行 - 我会使用模型侦听器。原因是,多个视图和演示者可以在一个模型上协同工作。当他们更改模型时,该更改应该发送到服务器。也许您不想立即执行此操作,但在发送之前收集一些更改。在这种情况下,您可以拥有一个由 AppController 设置的计时器。

The GWT tutorial page you linked to says about the AppController:

To handle logic that is not specific
to any presenter and instead resides
at the application layer, we'll
introduce the AppController component.

So it's the glue between multiple Presenters, Views and the Model (maybe multiple Models). It also handles the browser history. And maybe additional things that aren't specific to one presenter.

As for the server call: There are several options, but I personally wouldn't do it from the view, and also not from the presenter - I'd use a model listener. The reason is, that multiple views and presenters can work together on one model. And when they change the model, that change should be sent to the server. Maybe you don't want to do that immediately, but collect a few changes before you send them. In that case, you could have a timer that's set up - well - by the AppController.

温馨耳语 2024-09-25 07:27:48

回答你的最后一段,我想说,如果视图上有一些东西(某个按钮)应该执行此操作,你应该在演示者中执行此操作。 Presenter<在逻辑上与视图紧密相关(从技术上讲,它应该是弱相关的,仅通过接口而不是实现)。如果您想保存某些未从视图中显式调用的操作的记录,我不会在演示者中执行此操作。

Answering to your last paragraph, I would say you should do it in presenter if there is something (some button) on view that is supposed to do it. Presenter is logically strongly tied to view (technically it should be weakly tied, by interfaces only not by implementations). If you want to save the record on some action which is not explicitly called from view, I wouldn't do it in presenter.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文