5

我刚读了这篇文章，确实让我很困惑。

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

这是我遵循这种设计模式的全部好处吗？它似乎使代码更复杂......你使用这种模式吗？

4

3 回答 3

8

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

MVP 的主要好处（我的意思是 MVP 模式——不仅仅是 GWT MVP）：

  • GWT UI 和业务逻辑清晰分离；您的所有客户端 Java 代码都变得非常通用，对 GWT 实现的依赖最小（主要通过接口）。这极大地帮助了测试，但它本身就是 UI 设计的无价之宝。
  • 由于几乎不依赖业务逻辑，UI 的可维护性增加
  • 由于有限的 GWT 依赖关系，增加了客户端和服务器之间的共享代码量

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

  • gwt-gin（Google Guice 的客户端实现）：gwtp 使它几乎是必需的（或必需的——我从来没有尝试过没有它）
  • Guice（服务器端）与客户端代码保持一致，但在技术上不是必需的
  • 测试模拟框架（例如 mockito）总是与 MVP 一起得心应手
  • GWT UIBinder - 除非你在你的 UI 设计中非常有活力
  • GWT EventBus - AJAX/JavaScript 等异步环境中客户端通信的主要方法
  • GWT-RPC 通过命令模式（gwtp dispatcher 和/或 RequestFactory）
于 2011-03-07T16:40:57.407 回答
0

相比有什么优势？如果您的意思是与标准 MVC 模式（UI 开发的常见模式）相比的优势，那么是的，我想这是这种模式的主要原因

GWTTestCases 比标准的 junit 测试要慢得多且麻烦得多。您希望使用标准 java 测试框架测试逻辑，并使用 GWTTestCase 仅测试 UI 特定逻辑。

于 2011-03-06T17:02:31.693 回答
0

不使用 GWTTestCase 的事实非常棒，特别是如果您进行测试驱动开发，但还有其他很大的好处，比如提到的 topchef。这取决于您使用的 MVP 的“版本”。当我看到人们将 Presenter 注册为从视图中公开的小部件的侦听器时，我感到畏缩。

一般而言，围绕 MVP 的问题之一是有多种风格，新接触该模式的人会感到困惑，因为每种风格都有不同的优点和缺点。您可以查看这两篇文章，以帮助确定它是否适合您并获取有关 MVP 的更多详细信息（以及您可能会混淆的其他内容）：GWT MVP Pattern和GWT MVP，Activities and Places Confusion。

于 2012-09-07T11:30:10.167 回答