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

Question

将 Clean Architecture 与 flutter 结合使用时，我们会看到类似于此的图表:

(我以 MobX 包为例，但它可以是 BLoC、Redux 之类的东西……)
由于 Store 驻留在表示层和 中，我可能对这个图有问题。负责改变状态 .
想象一下，应用程序通过 TodosStore 中名为“getTodos”implementend 的方法加载一个待办事项列表。
“getTodos”实现可能是:

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

(我把事情简单化了)
它首先将状态更新为加载，调用用例返回列表并将状态设置为完成。
我在这里发现的问题:

店家负责用于调用 UC、更新状态、处理错误...

用例只是一个桥梁，不处理业务逻辑

这是一个相当简单的例子。
但是让我们想象一下，我有一个包含 3 个不同数据列表的 View (这可能是一个荒谬的例子)。
该 View 与 3 个不同的商店交互。应用栏中有一个按钮。它的目标是清除 3 个列表。
如何实现这种行为？

按钮 onPressed 方法需要为每个商店调用“clearData”

每个商店的“清除”方法将简单地更新其属性

问题是这个观点并不像我们想要的那么愚蠢。
本店 甚至不与任何用例交互
ClearLists 用例在这里是否合法？
由于我不喜欢在表示层有太多逻辑，我倾向于遵循以下图表:

每个 View 都有自己的 ViewModel。 VM 只是与用例交互。这些 UC 可能会也可能不会返回一个值。例如:我的 UC 是一个 ValidateNumberRange，我可能不会与商店进行交互。返回一个 bool 值是有意义的。但如果我的 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

Use cases encapsulate business rules, and they are platform-agnostic and delivery-mechanism-agnostic (e.g. UI).Use Cases are based on functionality, but without implementation details.Book:https://dannorth.net/introducing-bdd

改变状态是表现层的责任；表示层 != UI 层
像这样思考:

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

依赖关系应该总是向内的。
像这样想象:无副作用的业务逻辑(功能核心)始终处于中心位置，其余(有状态元素、UI、框架)围绕着它。
从你的图表:
AppState 和 ViewModel 始终驻留在表示层。 Flutter 特定的类属于 UI。