MVP模式（GWT）的优点是什么 [英] What is the advantage of the MVP pattern (GWT)

问题描述

我刚刚阅读了这篇文章和它确实混淆了我很多。

I just read this article and it did confuse me a lot.

其次，这个模型允许我们最小化使用GWTTestCase，它依赖于浏览器的存在，我们的代码，编写轻量级（和快速）JRE测试（不需要浏览器）。 [1]

这是整体的好处，我从遵循这种设计模式？似乎使代码更复杂...你使用这种模式？

Is this the whole benefit, I have from following this design pattern? It seems to make the code more complex... Do you use this pattern?

推荐答案

我不得不不同意，MVP使代码方式不那么复杂，特别是在GWT的情况下。如果您计划中型到大型GWT项目，则MVP架构是您的主要选择。我建议您查看GWT MVP（由Google）和gwt-platform（由KennethJ建议）。还有其他实现。

I have to disagree, MVP makes code way less complex, especially in case of GWT. If you plan on medium to large size GWT project then MVP architecture is your primary option. I suggest to look at both GWT MVP (by Google) and at gwt-platform (suggested by KennethJ). There are other implementations as well.

MVP的主要优点（我的意思是MVP模式 - 不仅仅是GWT MVP）：

MVP's main benefits (I mean MVP pattern - not just GWT MVP):

• 清除GWT UI和
  业务逻辑的分离;所有您的客户端
  Java代码变得非常通用
  ，最小程度上依赖于GWT
  实现（主要通过
  接口）。这有助于测试
  ，但它是非常宝贵的
  利益的UI设计本身。


• UI的可维护性由于几乎不依赖于业务
  逻辑


• 由于
  有限的GWT依赖关系，增加了客户端和服务器之间的共享代码量

您可能采用的其他补充技术：

Other complementing technologies that you are likely to adopt:

• gwt-gin（Google Guice的客户端实现）：gwtp几乎需要（或必需的 - 我从来没有尝试过）


• Guice（服务器端）与客户端代码一致，但在技术上不是必需的


• 测试嘲笑框架


• GWT EventBus - 客户端的主要方法（如mockito）总是适合MVP


• GWT UIBinder - 除非您在UI设计中非常动态在异步环境中的通信，如AJAX / JavaScript


• GWT-RPC通过命令模式（gwtp dispatcher和/或RequestFact ory）

• gwt-gin (client side implementation of Google Guice): gwtp makes it almost required (or required - I never tried without it)
• Guice (server side) for consistency with client code but not necessary technically
• test mocking framework (e.g. mockito) always comes handy with MVP
• GWT UIBinder - unless you are extremely dynamic in your UI design
• GWT EventBus - main method of client side communication in asynchronous environment like AJAX/JavaScript
• GWT-RPC via command pattern (gwtp dispatcher and/or RequestFactory)

这篇关于MVP模式（GWT）的优点是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！