Question

考虑从服务获取数据并使用MVP模式实现的表单的情况。我是否需要在单独的类中隔离服务访问，或者可以将其保存在Model类本身中。在我的特定情况下，模型类仅作为传递给最终调用服务的数据访问类的传递。数据访问类具有用于服务回调的逻辑，并在特定时间间隔内查询服务以进行任何更新。

我问这个问题，因为我希望我的代码结构尽可能简单，只在需要时才使用其他类。但我也不想简化它，以至于未来的维护/扩展变得非常困难。

Answer 1

Presenter可以使用将与Web服务通信的存储库。

public class SomePresenter
{
    private readonly ISomeView _view;
    private readonly ISomeRepository _repository;

    public class SomePresenter(ISomeView view, ISomeRepository repository)
    {
        _view = view;
        _repository = repository;
    }

    public void Foo()
    {
        var model = _repository.GetModel();
        // TODO: work with the model and update the view
    }
}

在实例化演示者时，您将传递存储库的实际实现，该实现将与Web服务进行通信。

Answer 2

简单的代码结构（意味着少量的类）并不一定意味着易于维护（see Ayende's recent post on this）。我的建议是遵守单一责任原则（SRP）。模型在MVP中的职责是将数据封装到视图中，但在您的情况下它还有另一个责任：从服务中获取数据。除了责任超载之外，我还看到了另外两个问题：

如果对服务的调用失败，会发生什么？然后你将被迫在视图的代码中处理它。
演示者对您的案件负有哪些责任？

在我看来，你的架构不是真正的MVP（但没有看到代码，我可能是错的）。

此外，MVP模式的实际实现取决于您使用的GUI技术。我的一般建议是：

坚持Passive View模式。
保持模特哑。我通常使用简单的POCO / POJO类，没有回调。我在WinForms中使用C＃视图事件来通知演示者任何UI事件。
使模型视图友好：通常应该为视图的需要实现模型，以便将视图代码保持在最低限度。
主持人是国王。将所有业务逻辑保留在演示者（以及其他服务/存储库）中。

更新：回答您的评论：

是的，您应该将数据存储在模型中。
如果我理解正确，您可以在模型中公开事件/回调以处理异常。然后让视图获取数据，并且在服务调用失败的情况下，演示者通过（再次）调用视图来处理此操作以让用户知道服务失败。我看到这种方法有几个问题：
1. 当发生服务异常时，它可以创建复杂的执行路径：presenter - ＆gt;查看 - ＆gt;模型 - ＆gt;演示者 - ＆gt;视图。调试和单元测试可能很棘手。
2. 当发生异常时，您如何知道视图的 where （就使用模型数据填充视图而言）？

我通常的做法是让演示者在视图获取模型数据之前执行所有提取和异常处理。这样我在模型中就不需要任何回调，因为我可以在演示者中使用简单的try-catch块来处理异常。该模型只是静态数据的持有者，而不是后端服务的门户。

Answer 3

此类通常称为服务代理。 Service Agent用于服务和客户端之间的松散耦合以及支持某些中间逻辑。根据您的描述，您的数据访问类已经是服务代理。

在为表单使用MVP时使用单独的类连接到服务

3 个答案: