Model View Presenter - 如何在 IView 界面中实现复杂的属性

Question

我发现很难理解如何最好地实现不是简单类型的“IView”接口属性，并且想知道其他人如何在模型视图演示器应用程序中处理此问题。

我读过的文章非常好，但它们似乎都没有涉及更复杂的视图，其中您有 List<> 。属于接口类型的属性，代表域模型中的类，即 IPerson 或 IName 等。

我将尝试尽可能简要地概述一个场景。

假设我需要一个视图最终保留一个名称列表，每个名称由 3 个属性“Forename”、“Surname”和“Title”组成。

通常我会有一个域模型，其中有一个名为“Name”的类，具有 3 个属性。该域模型将实现一个名为“IName”的接口（在单独的“接口”类库中）。

现在，在“Interaces”库的“Views”命名空间中，我有一个名为“IViewNames”的接口。这是任何想要最终保留名称列表的视图都将实现的视图接口。

如何定义这个“IViewNames”接口让我困惑。如果我给它一个像这样的属性：

public List<IName> Names {get;set;}

那么我实现的具体视图最终将有一个复杂的属性“Names”，它将需要一个“getter”，它循环遍历视图上的字段，以某种方式实例化“IName”的实例，设置其属性，在返回列表之前添加到列表中。 “setter”将同样复杂，接收“IName”列表并迭代它们以在视图上设置字段。

我觉得这打破了 MVP 方法的主要目标之一，即能够在没有任何具体视图实现的情况下彻底测试应用程序代码。毕竟，我可以轻松地编写一个演示者，它查看“View.Names”属性并将其发送到服务层，或者在从服务接收“Name”对象列表时设置“View.Names”属性层。我可以轻松地编写大量测试来确保一切正常，除了视图中的 COMPLEX 属性之外的一切。

所以我的问题是，其他人如何处理不是简单类型但实际上是域模型类型的 IView 属性？ （代表您的域模型的接口类型，因为我显然不希望从我的表示层到我的域模型层的引用）。

我非常确定有一种已知的技术可以以优雅的方式实现这一目标，它比我的示例方法更符合模型视图演示者的目标。

预先感谢任何帮助的人。

Answer 1

我对 MVP 设计模式没有做过太多研究，但肯定会尝试一下。

方法1：数据绑定

在这种情况下，您还可以在 IView 中创建单独的属性，并将演示器中的这些属性绑定到模型属性。这样，你的观点就不会变得复杂。由于 UI 中的值可以直接在模型中使用，因此体验快速且无缝。更改模型中的属性值将立即反映在 UI 中。为此，您可能必须使用 NotifyPropertyChange 事件。

方法 2：复杂类型

您可以尝试创建列表或元组来存储这些值并在演示器中使用这些值。您可能必须使用事件或操作来反映从模型到视图的值，反之亦然。

如果对您有帮助，请告诉我。谢谢。

Answer 2

我从其中一篇文章中取消了这个解释我在我的网站上写道

Presenter to View Communication

有两种样式用于使用我使用的 Presenter 和模型中的数据填充视图。它们之间的唯一区别在于您介意视图与模型的耦合程度。对于这个例子，我们将使用以下作为我们的模型：

public class Person
{
    public int ID { get; private set; }
    public int Age { get; set; }
    public String FirstName { get; set; }
    public String LastName { get; set; }
    Public Genders Gender { get; set; }
}

方法 1：使用模型

现在我们的视图代码：

public interface IEmployeesView
{
    void ClearList();
    void PopulateList(IEnumerable<Person> people);
}

最后是 Presenter：

public class IEmployeesPresenter
{
    public void Display()
    {
        _view.ClearList();
        _view.PopulateList(_model.AllEmployees);
    }
}

这种填充方法在模型和视图之间产生链接；用作 PopulateList 中参数的 Person 对象。

这样做的优点是 IEmployeesView 的具体实现可以决定在其人员列表中显示什么内容，从 Person 的任何或所有属性中进行选择。

这是该方法的两个缺点。第一个是没有什么可以阻止 View 调用 Person 上的方法，这使得惰性代码很容易溜进去。第二个是如果模型从 更改为例如，将 List 更改为 List，不仅模型和演示者需要更改，视图也需要更改。

方法 2：使用泛型类型

另一种方法依赖于使用 Tuple<...>、KeyValuePair<,> 以及自定义类和结构：

现在是我们的视图代码：

public interface IEmployeesView
{
    void ClearList();
    void PopulateList(IEnumerable<Tuple<int, String> names);
}

最后是Presenter：

public class IEmployeesPresenter
{
    public void Display()
    {
        var names = _model.AllEmployees.Select(x => new Tuple<int, String>(x.ID, x.FirstName + " " + x.LastName));

        _view.ClearList();
        _view.PopulateList(names);
    }
}

这种填充方法的优点是Model可以自由改变而不需要更新View，并且View无需决定显示什么。它还可以防止视图调用 Person 上的任何额外方法，因为它没有对其的引用。

这种方法的缺点是，您失去了强类型和可发现性 - Person 是什么非常明显，但 Tuple 则不太明显明显的。