Question

视图是否在其接口中没有特定于事件的事件并调用presenter普通方法来处理事件而没有任何官方EventHandler？例如

// ASPX
protected void OnSaveButtonClicked(object sender, EventArgs e)
{
  _Presenter.OnSave();
}

或者视图是否应在其界面中定义事件EventHandlers并将这些事件明确地链接到控制页面上的事件

// View
    public interface IView
    {
 ...
        event EventHandler Saved;
 ...
    }

// ASPX Page implementing the view
    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        SaveButton.Click += delegate { Saved(this, e); };
    }

// Presenter
    internal Presenter(IView view,IRepository repository)
    {
       _view = view;
       _repository = repository;
       view.Saved += Save;
    }

第二个似乎是要添加的全部管道代码。

我的目的是了解每种风格的好处，而不仅仅是对其使用的一揽子答案。我的主要目标是清晰度和高价值可测试性。整体可测试性很重要，但我不会牺牲设计的简洁性和清晰度，以便能够添加另一种类型的测试，这种测试不会导致通过更简单的设计实现的测试案例获得太多的收益。如果一个设计选择没有更多可测试性，请包括它现在可以提供的测试类型的示例（伪代码很好），所以如果我足够重视那种类型的额外测试，我可以做出决定。谢谢！

更新：我的问题是否需要进一步澄清？

Answer 1

我不喜欢在界面中明确引用Button（或任何其他控件）。这意味着我们与控件的实现紧密相关。

在项目类型（例如Winforms和ASP）之间可以非常不同地实现控制。

这意味着可能需要针对不同的视图修改接口，这正是我们不想要的。 MVP的重点在于Presenter可以依赖稳定的界面，允许UI与模型分离，轻松替换具体视图和可测试性。

最好坚持使用不依赖于任何特定控件的接口上的属性和方法，并将实现细节留给具体视图。

Answer 2

我们刚刚使用webforms实现了MVP，并选择了更简单的选项，即在演示者上直接使用视图调用方法进行按钮事件等。

我们的理由是我们无法直接对视图进行单元测试（我们使用waitin来测试这一层），所以这里的主要目标是让一个单元可测试的演示者尽可能远离视图/模型。

根据我的经验，你无论如何都不会在WebForms中实现完全干净的MVP由于野兽的性质（他们真的很喜欢你只是在文件后面使用该代码......），所以我不会'挂掉它。

在一天结束时，您需要评估分离视图和表示逻辑的原因，并确定这两种方法是否会在以后帮助/阻碍您....

Answer 3

在视图的界面中，您应该引用保存按钮，然后一切都在提交者中完成。这样可以使您的视图无需代码，并且您的预览可以轻松测试。

// View interface
public interface IView
{
    Button SaveButton;
}

// View code behind
public Button SaveButton
{
   get { return btnSave; }
}

//  Presenter
internal Presenter(IView view,IRepository repository)
{
   _view = view;
   _repository = repository;
   view.SaveButton.Click += new EventHandler(Saved);;
}

void Saved(object sender, EventArgs e)
{
   // do save
}

Webforms MVP被动视图 - 事件处理

3 个答案: