Android Clean 架构

2021-01-19 本文已影响0人科技猿人

业务逻辑应该清楚地分开并且独立于框架

先看下我们熟悉的MVP架构

再看下我们熟悉的MVP+管理类

提前预览下Clean的架构

再来看下真正的主题 Android Clean

它也被称为洋葱架构，因为该图看起来像一个洋葱（当您意识到必须写多少样板时，它会让您哭泣）。或端口和适配器，因为如您所见，在右下角有一些端口。六角形架构是另一种相似的架构。
清洁架构是先前提到的Bob叔叔的创意，他还撰写了有关Clean Code和Clean Coder的书。这种方法的要点是，业务逻辑（也称为域）位于宇宙的中心。

依赖规则

外层应取决于内层。红场中的三个箭头表示依赖性。与其说“依赖”，不如使用“看见”，“知道”或“知道”之类的词。用这些术语，外层可以看到，知道和知道内层，但是内层既看不到也不知道，也不知道外层。如前所述，内层包含业务逻辑，外层包含实现细节。结合依赖规则，可以得出结论，业务逻辑既看不到也不知道，也不知道实现细节。而这正是我们正在努力实现的目标。

抽象化

以前已经暗示过抽象原理。它说，当您朝图的中间移动时，内容变得更加抽象。这是有道理的：正如我们所说的，内圈包含业务逻辑，外圈包含实现细节。
如图所示，您甚至可以将相同的逻辑组件划分在多个层之间。可以在内层中定义更抽象的部分，而在外层中定义更具体的部分。

您可以在该图中看到标准三层体系结构中的所有依赖关系都进入了数据库。这意味着抽象和依赖关系不匹配。从逻辑上讲，业务层应该是应用程序的中心，但并不是，因为依赖关系会进入数据库。
在干净的体系结构中，依赖项进入业务（内部）层，而抽象也向业务层发展，因此它们匹配得很好。
这很重要，因为抽象是理论，而依赖是实践。抽象是应用程序的逻辑布局，而依赖关系是应用程序实际组合在一起的方式。在干净的体系结构中，这两个匹配，而在标准的三层体系结构中，它们不匹配。如果您不小心，可能很快导致各种逻辑上的不一致和混乱。

层间通讯

现在，我们已经将应用程序划分为模块，将所有内容很好地分离了，将业务逻辑放在应用程序的中心，而实现细节则在郊区，一切看起来都很棒。但是您可能很快就遇到了一个有趣的问题。
如果您的UI是实现细节，互联网是实现细节，并且业务逻辑介于两者之间，那么我们如何从互联网上获取数据，通过业务逻辑传递数据，然后将其发送到屏幕？
业务逻辑位于中间，应该在Internet和UI之间进行调解，但它甚至不知道这两个家伙是否存在。这是通信和数据流的问题。
我们只有两层，绿色一层和红色一层。绿色的一个在外面，知道红色，红色的一个在里面，只知道自己。我们希望数据从绿色的一到红色的一再回到绿色的一。解决方案之前已经暗示过，并在下图中显示：
右下角的图部分显示了数据流。数据从控制器输入，通过用例（或用您选择的组件替换用例）输入端口，然后通过用例本身，然后通过用例输出端口返回到演示者。

输入端口是一个接口，实际的实现是用例：因此它在用例上调用了一个方法，数据流到该用例。用例做了一些事情，想将数据发送回去。它具有对输出端口的引用（因为输出端口是在同一层中定义的），因此它可以在其上调用方法。因此，数据进入输出端口。最后，演示者是或实现输出端口。那是神奇的部分。当它实现输出端口时，数据实际上流入其中。
定义其输入和输出端口是内层的责任，以便外层可以使用它们与之建立通信。我们在内部层定义了一个通知接口，业务逻辑可以使用该接口向用户显示通知，但是在外部层也定义了一个实现。在这种情况下，通知接口是业务逻辑的输出端口，它用于与外部世界进行通信-在此示例中为具体实现。