Android清洁架构-单独使用，单一Usecase，还是根本没有Usecase？

Question

我正致力于重构我的一个旧项目，以遵循清洁架构范式(到目前为止，我很喜欢它)，我的一个组件在是否应该作为UseCase存在方面给我带来了一些困惑。

例如，简单的例子是，有一个联系人信息屏幕，它将显示先前的答案，并使用户能够提交更新。

我是否有两个用例(1个用户提交联系人信息，1个视图联系人信息)。

或者仅仅是一个UseCase (编辑联系人信息，有两个函数返回以前的和也提交)？

我的实际示例Bold是我在下面不确定的用例，如果您想跳过它的话。

屏幕本身是一个由10个图像组成的网格，用户可以在其中进行选择，以便在应用程序的其他地方显示该图像。其中九个是项目中的资源，一个是用户可以上传自己的图像的地方，用户的选择存储在共享首选项中。

用例：

1. 用户选择一个图像，这肯定是一个用例，它背后的业务逻辑对我来说是有意义的。用户正在视图层中执行操作，我将使用它们的选择更新数据层(存储库)。太完美了。
2. 用户上传他们自己的图像-这也是一个用例。用户上传他们的图像，并做一些工作来存储它，以及选择它作为他们的选择。所以在一个用例中有两个功能，这是有意义的。它符合整个要求。完美
3. 向用户显示选项？-这是向循环抛出我的选项。因此，当用户导航到此屏幕时，我需要首先显示供用户选择的10个选项，以及高亮显示先前选择的image.So，这是一个单独的用例，我可以说显示选项还是获取选项？或者，由于这些图像中有9个在资源中，这仅仅是我视图的一部分吗？如果是这样的话，我是否只为检索用户上传的图像创建了一个用例？

我知道我还有一些类似于设置初始数据集的例子。

大多数情况下，它来自于一个API或数据库，它是一个更完整的业务规则的一部分，作为一个UseCase是有意义的。对于这种情况，我有点不确定，在这种情况下，我可能是从一个文件中读取，或者是从一些现有资源中加载。

谢谢你的建议！

Answer 1

是关于用例还是用户界面?

您所称的用例似乎是用户界面的详细规范：

• 屏幕本身就是一个由.
• 用户选择图像..。
• 用户上传自己的图片..。

换句话说，你的注意力更多的是“如何”而不是“什么”。所以第一个要问的问题是你想要记录什么。

是用户界面吗?

当然，您可以为此目的使用用例(UC)。但这可能是次优的过度杀戮: UC中描述的操作与用户界面元素之间的联系尚不清楚；此外，UC并不意味着记录有备选方案的有序操作序列。

自发地，我建议使用几个线框来非常有效地表达这样的事情。

如果用户界面很复杂，并且需要一些操作序列，那么您可以考虑活动图而不是用例。

还是关于系统用途的？

用例更能有效地描述系统的目的，即用户将与系统交互的目标。重点应该放在大局上，而不是细节上。

例如，我理解应用程序用户的目标不是管理和上传图片，也不是与网格搏斗；目标是管理资源(主要用例)。用例可以分解为用户想要达到的子目标，例如系统应该允许用户对资源做什么。通常情况下，可以是维护资源目录，描述单个资源，为项目分配资源，等等。

如何在系统中实现这些用例取决于系统的设计。例如，可以想象单个屏幕应用程序允许启动所有用例。或者，您也可以定义一个事务性系统，其中每个用例都有其特定的用户界面。

附加读数

我强烈推荐你艾瓦尔雅各布森的用例2.0免费电子书。Jacobson发明了UML的用例方法。在这本电子书中，他阐明了用例的主要意图，以及它们如何在现代敏捷环境中使用。