2010-09-10 28 views
0

考虑一种表单从服务中获取其数据并使用MVP模式实现的情况。我是否需要在单独的课程中隔离服务访问权限,还是可以将其保留在Model类本身中。在我的特殊情况下,模型类只能作为传递给最终调用服务的数据访问类的传递。数据访问类具有用于服务回调和在特定时间间隔内查询服务以进行任何更新的逻辑。使用单独的类连接到服务时使用MVP表单

我在问这个,因为我想保持我的代码结构尽可能简单,并且只在需要的时候使用额外的类。但我也不想简化它,以至于将来的维护/扩展会变得非常困难。

回答

1

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

  1. 如果对服务的调用失败会发生什么?那么你将被迫在视图的代码中处理这个问题。
  2. 主持人对你的情况有什么责任?

在我看来,你的架构不是真正的MVP(但没有看到代码,我可能是错的)。

此外,MVP模式的实际实施取决于您使用的GUI技术。我的一般建议:

  • 坚持Passive View模式。
  • 保持模型愚蠢。我通常使用简单的POCO/POJO类,没有回调。我在WinForms中使用C#视图事件来通知演示者任何UI事件。
  • 使模型易于查看:模型通常应该根据视图的需要来实现,以便将视图代码保持在最低限度。
  • 演示者是国王。保持演示者(和其他服务/存储库)中的所有业务逻辑。

UPDATE:回答您的评论:

  • 是的,你应该将数据存储在您的模型。
  • 如果我理解正确,您将在模型中公开事件/回调来处理异常。然后让视图获取数据,并且在服务调用失败的情况下,演示者通过(再次)调用视图来让用户知道服务失败。我看到几个问题,这种方法:

    1. 当服务出现异常时,可创造令人费解的执行路径:主持人 - >查看 - >模型 - >演示 - >视图。这对于调试和单元测试可能非常棘手。
    2. 您如何知道其中当异常发生时,视图(用填充视图和模型数据的方式)?

我通常的做法,是由主持人做所有的获取和异常处理以前视图获取其手中的模型数据。这样我就不需要模型中的任何回调,因为我可以在演示器中用简单的try-catch块来处理异常。该模型仅仅成为静态数据的持有者,而不是后端服务的入口。

+0

我正在使用被动视图模式。演示者创建并处理视图和模型。业务逻辑(过滤,搜索和导出数据)在主讲人中。该模型的责任是获取数据并将其转换为视图消耗的绑定列表(通过演示者)。但数据需要存储在某个地方。我是否将其存储在模型中?另外,我认为如果服务失败,模型会返回一个信息,然后通知用户“服务不可用”。我仍然不明白为什么模特不会直接访问servuce – EndlessSpace 2010-09-10 19:31:49

+0

如果您觉得您的方法适合您,请继续使用它。我根据您的评论更新了我的答案。 – 2010-09-11 03:43:56

+1

我想我已经明白你在这里想告诉我什么。我将根据您的输入更改我的mvp课程。视图只会由演示者更新。模型存储所有数据。演示者管理从模型中获取数据,更新视图并响应视图中的事件。希望这会让我的代码更容易被任何第三人理解。感谢您的输入。 – EndlessSpace 2010-09-13 15:54:47

1

演示者可以使用将与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服务进行通信。

0

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