处理多个数据源时如何在 MVP 架构中使用模型答案

【问题标题】：How to use the Model in a MVP architecture, when working with multiple datasources处理多个数据源时如何在 MVP 架构中使用模型
【发布时间】：2013-08-27 06:32:37
【问题描述】：

现在似乎人们喜欢以不同的方式使用 MVP 模式，有些人更喜欢视图完全不知道模型并让演示者“提供”数据，而有些人更喜欢只将模型提供给视图并让视图直接从模型中读取其数据。就个人而言，我更喜欢后者。

在阅读 MVP 时，似乎所有示例都或多或少地集中在处理一种数据类型的 CRUD 视图上。但在现实世界中，我们的视图可以处理多个数据源。例如，假设我们有一个设置视图，可以处理不同类型的数据，例如 SystemSettings、WorkflowSettings 和 UserSettings（我们不要争论 UX，这只是为了举例）。

我的第一个问题是，您如何为使用多个数据源的视图定义“模型”？我的意思是，您的视图是否有设置不同“模型”（setSystemSettings()、setWorkflowSettings()、...）的方法，或者您是否将实际的域模型包装在 DTO 中并且只有一个简单的 setModel(settingsDto) 方法在你看来？

【问题讨论】：

模型是一个层（您可以通过 services 与之交互，就像在其他受 MVC 启发的模式中一样，然后依次处理 域对象之间的交互 和存储抽象）。而且您不会定义“查看”任何内容。 MVP pattern 的全部意义在于数据是由presenter提供给视图的。
在 MVP 模式的 doplhin-smalltalk 定义中，Model 通常是领域模型，位于领域层。无论您将模型视为层还是其他东西，您都可能拥有一个处理多种类型数据的视图。我的问题是，你如何处理这个问题，你是将多个领域模型包装到一个对象中，然后再提供给视图，还是你的视图直接处理多个领域模型？

标签： design-patterns model-view-controller user-interface architecture mvp

【解决方案1】：

对我来说，“模型”是抽象的。我现在将模型视为“Presenter 完成工作所需的任何东西”。

因此，鉴于您的示例，我的方法可能是将我的模型定义为 RepositoryFactory，它允许我的演示者创建获取其数据所需的适当存储库。

这仍然允许进行单元测试。

【讨论】：