在清晰的架构中定义演示者和输出端口的最佳方式？

Question

我一直在尝试遵循清晰的架构来开发应用程序。 鲍勃叔叔的干净架构所建议的大部分内容在理论上都是有意义的。

如图所示，

系统的所有用例都定义了输出端口，它返回操作的结果。演示者展示结果，

但问题是，

1. 输出端口是否有任何实际分组，似乎输出端口是链接的抽象/接口的集合到一个用例。 因此，假设我们有 5 个用例，它们会产生一些输出数据，并且在触发用例和报告结果之间存在一段时间的延迟，所以这意味着我们也必须处理它。这将使输出端口现在有 5*2 接口，由 Presenter 实现。

2. 来到Web应用程序中的presenter，Web应用程序有很多页面，这些页面可以称为视图。那么，我们是否创建一个实现所有用例输出接口的单个​​演示者？演示者决定渲染哪个视图、什么数据。 ？这种方法的问题在于，它使演示者成为一个非常大的类，它实现了所有用例输出。 或者我们为每个 UI 页面创建一个演示者，它仅实现相关的用例输出端口。？

3. 同样的问题也适用于控制器，是否每个视图都有一个大控制器和多个小控制器。

Answer 1

1. 输出端口是否有任何实际的分组，输出端口似乎是链接到一个用例的抽象/接口的集合。因此，假设我们有 5 个用例，它们会产生一些输出数据，并且在触发用例和报告结果之间存在一段时间的延迟，所以这意味着我们也必须处理它。这将使输出端口现在有 5*2 接口，由 Presenter 实现。

编辑

我的意思是触发用例和生成输出之间的加载等待，因此每个用例有两个接口，一个用于报告加载时间，一个在加载完成后报告数据。

因此，当您想要报告用例的进度时，您有多种选择。

1. 向输出端口添加进度方法

   公共接口OutputPort {
        公共无效setResponse（ResponseData rd）；
        public void reportProgress(Progress 进度);
   }
   

2. 扩展进度接口

   公共接口 ProgressOutputPort {
        public void reportProgress(Progress 进度);
   }
   
   公共接口 OutputPort 扩展 ProgressOutputPort {
        公共无效setResponse（ResponseData rd）；
   }
   

3. 进度响应数据

   公共类 ResponseData {
       进步进步；
       ???结果;
   }
   

4. 扩展进度响应数据

   公共类 ProgressData {
       进步进步；
   }
   
   公共类 ResponseData 扩展 ProgressData {
       ???结果;
   }
   

我无法在这里讨论所有不同的优缺点，但我想我会使用 2. 或 4. 选项。

来到Web应用程序中的presenter，Web应用程序有很多页面，这些页面可以称为视图。那么，我们是否创建一个实现所有用例输出接口的单个​​演示者？演示者决定渲染哪个视图、什么数据。 ？这种方法的问题在于，它使演示者成为一个非常大的类，它实现了所有用例输出。或者我们为每个 UI 页面创建一个演示者，它仅实现相关的用例输出端口。

演示者的概念并不意味着只有一个。此外，如果只有一个，它将承担很多责任，因此会因不同的原因而发生变化。这将违反单一责任原则。这并不一定意味着您必须为每个输出端口创建一个新的演示器。但通常不同的输出端口会因不同的原因而改变。

我还认为，由于测试原因，将不同的演示者分开会更好。例如，如果您只有一个实现所有输出端口的演示者，那么它还依赖于它可以更新的所有视图模型。这意味着您经常必须模拟某个测试的依赖关系，而该特定测试不需要这些依赖关系。

同样的问题也适用于控制器，是否每个视图都有一个大控制器和多个小控制器。

与我对 2 给出的答案相同。演示者可以应用于控制器。

控制器根据用户交互执行用例。这可以是按钮的点击、触摸设备上的手指手势、移动设备的陀螺仪传感器的状态改变或者任何用户交互。因此，控制器由 ui 发出的事件触发。控制器解释用户交互，并通过将用户输入从视图模型传递到用例来将其转换为用例调用。您经常使用演示器将视图模型的更新与用例的结果封装起来。

编辑

所以，最好每页都有演示者和控制器。 ？

是的，甚至更细粒度。也许一个用例仅适用于页面的一部分，因此您也有该部分的控制器和演示者。

在某些情况下，您可以将演示者和/或控制器合并到一个对象中，但我想这种情况很少见。最后当应用程序发展时你会看到它。有时您合并对象，后来您发现这不是一个好主意，然后您再次拆分它们。也许与合并之前的结构相同，也许您会发现另一个更合适的结构。