在 Flutter 中使用 Clean Architecture 在哪里执行状态更改？

Question

当将 Clean Architecture 与 flutter 结合使用时，我们会看到类似这样的图表：

（我编写了 MobX 包作为示例，但它可以是 BLoC、Redux 之类的任何东西......）

我可能对该图有疑问，因为 Store 驻留在表示层中并负责更改状态。

想象一下，应用程序通过 TodosStore 中名为“getTodos”implementend 的方法加载待办事项列表。“getTodos”的实现可能是：

 _state = State.loading();
 final result = GetTodos();
 _state = State.done();

（我把事情过于简单化了）

它首先将状态更新为加载，调用返回列表的用例并将状态设置为完成。

我在这里发现的问题：

1. 商店负责调用UC、更新状态、处理错误......
2. 用例只是一个桥梁，不处理业务逻辑

这是一个相当简单的例子。但是让我们想象一下，我有一个包含 3 个不同数据列表的视图（这可能是一个荒谬的例子）。该视图与 3 个不同的商店交互。应用栏中有一个按钮。其目标是清除 3 个列表。

如何实现这种行为？

• 按钮 onPressed 方法需要为每个商店调用“clearData”
• 每个商店的“clear”方法将简单地更新其属性

问题是这个视图并不像我们想要的那么愚蠢。商店甚至不与任何用例交互

ClearLists 用例在这里应该合法吗？

由于我不喜欢在表示层中有太多逻辑，因此我倾向于遵循下图：

每个视图都有自己的 ViewModel。VM 只是与用例交互。这些 UC 可能返回值，也可能不返回值。例如：我的 UC 是 ValidateNumberRange，我可能不会与商店交互。返回一个布尔值是有意义的。但如果我的 UC 是 ClearTodoList，它可能会与商店交互。成功或失败可能是一个存储值。这样返回值可能没有用。

通过这个新图表，“GetTodos”用例可调用方法实现可能是：

store.set(State.loading());
final result = repo.getTodos();
result.fold(
   (failureMsg) { store.set(State.failure(failureMsg)); },
   (newList) { store.set(State.done(newList)); },
);

• 用例处理状态管理逻辑
• View调用VM方法。VM调用UC并观察Store中的变化（这里通过MobX）

我问自己很多问题：

• 我是否正确理解了 UC 在洁净架构中的作用？
• 更改状态（加载、完成、失败）是否被视为业务逻辑？
• 您会将状态管理解决方案放在应用程序中的什么位置？

我期待听到你的想法

Answer 1

用例封装了业务规则，并且它们与平台无关并且与交付机制无关（例如UI）。用例基于功能，但没有实现细节。书籍： https: //dannorth.net/introducing-bdd

改变状态是表示层的责任；表示层！= UI 层

像这样思考：

Domain Layer <= infrastructure layer <= application layer <= presentation layer <= UI Layer

依赖关系始终应该是向内的。想象一下：无副作用的业务逻辑（功能核心）始终位于中心，其余部分（有状态元素、UI、框架）围绕它。

从你的图表来看：AppState 和 ViewModel 始终驻留在表示层中。Flutter 特定的类属于 UI。