2012-05-31 92 views
4

我有一個表示插件的視圖類,以及伴隨演示者類。我還擁有一個擁有該窗口小部件的窗口的視圖類,以及窗口視圖的伴隨主持人。窗口操縱窗口小部件,所以我需要窗口呈現器與窗口小部件主持人進行通信。想象:模型/視圖/主持人:主持人對演示者通信

+-------------+  +------------------+ 
| widget_view |<------>| widget_presenter | 
+-------------+  +------------------+ 
    ^      ^
     |       | 
     |       V 
+-------------+  +------------------+ 
| window_view |<------>| window_presenter | 
+-------------+  +------------------+ 

我不確定的是如何構造對象。我知道MVP架構並沒有處理這個問題,而是「把它作爲讀者的練習」。事情我想:

  1. 的意見,構建自己的主持人,和window_view結構widget_view。但是,window_view在其構造函數中需要額外的參數,它不應該關心的參數,僅僅是實例化演示者。我也不確定window_presenter將如何訪問widget_presenter。添加一個widget_presenter setter到window_presenterwindow_view填寫不感覺對我來說是正確的。
  2. 消除兩位演示者之間的通信線路。 window_presenterwidget_presenter通過window_view對話。這對我來說也不太理想,因爲它僅需要將代碼添加到window_view,僅用於window_presenterwidget_presenter之間的通信。它也只允許單向溝通,並且它還增加了胖子widget_view以允許外人與其演示者進行交流。

我能想象的複雜性成倍增長這裏作爲window_presenter需要跟其他主持人或其他演示需要另一些其它的主持人交談。

我也想在這裏加入了調解對象吸收所有這些互相通信和相關性,但在這一點從表現分離邏輯的整體思路開始感到非常昂貴的和非常複雜的。當然,我在這裏做錯了事。

回答

0

我發現這篇文章,可能會幫助:

http://martinfowler.com/eaaDev/uiArchs.html

特別是,它看起來像你所談論的「經典」的MVC,每個插件是用自己的控制器的視圖。我認爲這篇文章談到了世界的「形式」觀點,每一個「形式」都是一個觀點的集合,而且只有一個控制者或主持人。我認爲MVP屬於「形式」觀點,因此通常每個表格都是一名主持人。