2013-03-20 18 views
1

我正在使用MVP模式的應用程序。它還處於開發初期,所以我仍然有着批判性地反思不同設計選擇的奢華。什麼是衆所周知的方法移動MVP中的圖層周圍的數據

模型是由一些結構和操作它們,爲了清楚起見一些API函數,讓我們說這是型號:

struct ComplexNumber { 
    double real; 
    double imag; 
}; 

Complex_Add(ComplexNumber x, ComplexNumber y); 
Complex_Mul(ComplexNumber x, ComplexNumber y); 

然後是查看。我在這裏只使用原始類型。

class IComplexView { 
public: 

    virtual double GetReal1() = 0; 
    virtual double GetImag1() = 0; 

    virtual double GetReal2() = 0; 
    virtual double GetImag2() = 0; 
    // Setters snipped 
}; 

現在演示,只要我能理解,我有查看到模型和模型到視圖數據轉換的幾種方法。我通常有一個ReadView()和一個UpdateView()方法。所以主持人的那部分看起來會很接近這個:

class ComplexPresenter { 
    ICopmlexView view; 
    ComplexNumber x; 
    ComplexNumber y; 

    // ... 

    static void ReadView() { 
     x.real = view.GetReal1(); 
     x.imag = view.GetImag1(); 

     y.real = view.GetReal2(); 
     y.imag = view.GetImag2(); 
    } 
} 

UpdateView()會倒過來,這樣的觀點是從模型填充。

使用該設置,問題是: 是否有一種「巧妙」的方式將視圖中的變量/屬性綁定到模型中的一個,而不是上面的簡單方法?

我這個看到的問題是添加的代碼只是四處移動數據的比較大的量。首先,我們在IView中具有acessors,然後是ReadView()和UpdateView()方法。我認爲腳本可以連接到構建事件並自動生成所有這些代碼,但我希望能有其他替代方案,我沒有注意到。

另一種方法是完全放棄MVP,或者具體來說,放棄演示者,只需要一個邏輯分隔即可。明顯的缺點是耦合性更強,但另一方面,它可能會導致代碼量明顯減少。您所描述的

+1

看一看在[管窺](http://www.martinfowler.com/eaaDev/uiArchs.html#HumbleView)。 – 2013-03-20 12:54:14

回答

2

MVP變體可爲下文稱作爲Passive View - 看看Martin Fowler's entry about it here。其缺點的確是大量的樣板代碼來同步模型和視圖。使用一些data binding機制的備選將是Supervising ControllerPresentation Model (aka View Model)

下降的主持人,只是有一個UI < - >邏輯分離,這就是它

一個這裏的危險在於,約束機制未必能夠處理複雜案件

一般,考慮這兩個解決方案:

  • Presentation Model可以採用綁定的兩層:視圖 - 演示文稿模型演示文稿 - 模型 - 域 - 模型綁定。它保持較低的耦合度,但實現這兩個機制本身可能是單調乏味的。

  • Supervising Controller使用視圖與域模型綁定和本身只處理複雜的情況下無法通過約束機制來處理,讓您獲得兩全其美。

相關問題