GWT MVP：最佳設計實踐

Question

我已經閱讀了GWT項目站點的MVP教程，該視圖僅應包含其包含的小部件的事件處理程序，並且處理它們的邏輯應駐留在presenter中。 對此我有以下疑問：

1. 很多時候，我們需要根據在視圖上接收到的事件來動態更改窗口小部件的樣式，那么在代理人中移動這種邏輯是否有意義？

2. 很多時候，我們需要從視圖中的多個字段獲取數據並創建一個對象，然后將其傳遞給某些小部件，例如cellTable，它具有自己的asyncDataProvider。 那么在為所有視圖字段創建getter和setter時是否有意義，以便演示者可以訪問它們並形成對象並初始化cellTable並將對象傳遞給它？ 在Presenter的視圖面板中添加小部件是個好主意嗎？

3. 我到處都讀到向演示者添加邏輯而不是視圖的原因是為了增加jUnit測試覆蓋率，從而節省了時間。 但是，據我所知，我們也可以在View上使用模擬框架來為其中的基本邏輯編寫測試用例。

4. 考慮到第3點，在視圖中編寫這么多的代碼（getters / setters）真的有意義嗎？ 我認為，只有在以下情況下，流程才應從主持人的角度返回：

   一種。 我們需要切換視圖

   灣 我們沒有要顯示的數據，因此演示者可以通過RPC提供數據

Answer 1

首先，請參閱Google IO 2013 中的GWT中的揭秘MVP和EventBus （ 幻燈片 ）演示。這是對整個MVP + GWT方法的更新，應該可以回答您的一些疑問和問題。

通常，有關MVP和設計應用程序體系結構，有很多意見和方法。 因此，YMMV。

1. 我問自己-這是數據狀態的變化嗎？ 還是只是演示文稿的更新？ 在后一種情況下，我會將其保留在視圖中，否則視圖的界面會變得不必要地過大。
2. 在這種情況下，您可能要考慮創建Editor 。 然后，您將使用編輯器的界面來編輯和刷新數據-您不必公開所有單獨的字段。
3. 是的，請參見上面的演示，其中提到在某些情況下將視圖和演示者分開是沒有意義的。 特別是當我們擁有gwtmockito之類的工具時。
4. 這取決於您如何對待視圖-它們是愚蠢的視圖，不包含邏輯並且由演示者控制嗎？ 一方面，這實現了很好的分離，另一方面，正如您提到的，視圖的界面往往變得非常冗長。 我嘗試針對這兩種方法之間的最佳結合點，但這實際上取決於您的編碼風格和用例。