基于状态的MVP更新视图

我试图实现MVP模式,或者我自己的解释/变体。 我很想知道我在做什么是可以接受的MVP模式。

举例来说,我有3个按钮和4个标签。 每个按钮也映射到一个状态。 例如,button1映射到state1,button2映射到state2,button3映射到state3。 点击每个按钮可以更改状态管理器类中保存的应用程序的状态。 状态管理器类使用观察者模式来通知观察者状态已经改变。

在我看来,我抓住用户输入,在这种情况下点击按钮,然后立即将事件传递给演示者。 所以我可能会有这样的事情。

button1.addActionListener(new ActionListener()
{
  public void actionPerformed(ActionEvent e)
  {
    presenter.btn1Pressed();
  }
});

然后我可能会在主持人中有一个方法,如下所示:

public void btn1Pressed(){
    stateManager.setState(state1);
}

现在州经理班改变其状态并通知其观察员。 所以在我的Presenter班上,我有:

@Override
public void stateChange(State state){
    switch(state){
    case state1:
        view.state1(); //view is an interface not a concrete.
        break;
    }
}

然后在我看来,我有state1方法:

@Override
public void state1(){
    button1.setEnabled(false);
    button2.setEnabled(false);
    button3.setEnabled(true);
    label1.setVisible(true);
    label2.setVisible(false);
    label3.setVisible(true);
    label4.setVisible(false);
}

所有的方法都不同。 例如,state2可能是:

@Override
public void state2(){
    button1.setEnabled(true);
    button2.setEnabled(false);
    button3.setEnabled(true);
    label1.setVisible(false);
    label2.setVisible(false);
    label3.setVisible(true);
    label4.setVisible(false);
}

因此,该视图具有如何呈现自身的知识,所以我不认为这是被动视图实现。 它也不是监督控制器,因为它不绑定到模型。 它显然确实有一些表示逻辑。 我试图彻底删除它并使其成为被动的观点,但它并不自然。 例如,当我试图使其成为被动视图时,我做了以下操作:

在我的主持人班上

private void state1(){
    view.setButton1Enabled(false);
    view.setButton2Enabled(false);
    //...
}

在视图中

public void setButton1Enabled(boolean enabled){
    button1.setEnabled(enabled);
}
public void setButton2Enabled(boolean enabled){
    button2.setEnabled(enabled);
}
//...

但是,这需要很多方法来处理。 我也尝试过一种演示模式模式,但是我觉得它只会让它变得更糟。

我更喜欢我的实现,尽管它在我的视图中保留了一些表示逻辑。 我的实施仍然适用于MVP? 我意识到模式是要解释的,但我很想知道在我的视图中留下少量的表示逻辑是否可行。


我认为你的实现非常多MVP。 如果我要对它进行分类,那么无论您引用的数据绑定机制如何,我都会倾向于成为监督控制器变体。 我说这是因为Presenter与View的交互非常“宏观”。 对我来说,被动视图变体会有更多的“微观”交互。

我通常会发现,如果视图只包含与特定事物相关的逻辑,那么这是可以接受的。 例如,项目列表可能在一个视图中表示为ListBox而在另一个视图中则实现相同的界面,则该列表可能被表示为ListView 。 因此,只有相关的视图才会知道每个上下文中SetState()含义。 我的一个MVP设计的“试金石测试”是我是否可以使用控制台代表视图。 不管这是否成为现实,我认为将设计和抽象层次恰到好处是有帮助的。

此外,视图中的逻辑不会自动降低可测试性。

对MVP设计始终牢记的另一件事是可测试性。 该模式的关键目标之一是支持自动化测试。 如果您的设计允许您以虚假视图自动完成对功能/用例行为的全面测试,那么恕我直言,您的设计就很好。

链接地址: http://www.djcxy.com/p/30235.html

上一篇: MVP update view based on state

下一篇: Presentation Model vs MVP (Passive View)