iOS：Tiendeo应用程序中的MVP清洁架构

Tiendeo移动部门在2017年面临着巨大挑战：从头开始重新制作该应用程序。

我们的旧版应用程序创建于2013年。它是使用简单的MVC架构，Objective-C（当然）构建的，它使用RestKit，AFNetworking和许多其他Pod …经过多年的开发和一些开发人员，它变得庞大，不可扩展，不稳定，具有大量的视图控制器，大量的AppDelegate，一些新功能都在Swift中进行了编码，还包含一些重构的部分，因此我们很少有Swift-Objective-C桥，……这是一个为孩子们吃早餐的怪物。

考虑到所有这些问题以及业务方向的一些变化，该公司与移动部门一起决定重新制作该应用程序。 ✨

因此，尽管我们为旧版应用程序提供了少量维护，但我们开始同时为Android和iOS两个平台构建新的应用程序。 这个事实标志着我们将使用的架构。

干净的建筑

我认为，根据我的经验，现代应用程序体系结构必须健壮，稳定，可扩展，可测试，适应更改和可维护。 我认为干净的架构可以提供所有这些功能。

基本上，干净的体系结构使用依赖规则将代码构建在同心层中： 内圈中的任何人都无法完全了解外圈中的任何事物。 特别是，在内圈中的代码不得提及在外圈中声明的名称。 其中包括功能，类。 变量或任何其他命名的软件实体。

只有一条规则！ 太酷了！ 👌内部层包含业务逻辑，中间层包含控制器和用例，外部层包含UI，框架，DB等。

当系统的任何外部部分（例如数据库或框架）变得过时时，都可以通过这种方式构造代码，您可以用最少的麻烦替换那些过时的元素 。

存档的一些关键技术优势包括：

• 实现的抽象
• 单一责任原则
• 关注点分离
• 解耦代码

在进行了这一简短介绍之后，让我们回到我们的故事！

MVP +清洁架构

我们决定在两个平台上都使用ReactiveX来应用MVP和干净的体系结构。 我们还尝试在两个平台上保持相同的类和函数命名。

以这种方式保持两个平台同步对我们来说真是太棒了，因为当我们计划新功能或讨论错误等时，两个团队都在谈论相同的组件，相同的结构，几乎相同的方法名称，即使一个开发人员想要切换到在另一个平台上，这种方式要容易得多。

构成我们的体系结构的层是：

• UI层
• 域层
• 资料层

这是体系结构的方案：

让我们来研究一下：

UI层

• 我们将MVP用于UI层。
• 我们使用依赖注入将依赖项注入到Presenter中，例如：用例，自定义对象等。
• Presenter在用例和视图控制器之间居于中间。 它处理用户交互，启动适当的业务逻辑并将响应发送到视图控制器。
• Presenter不会导入UIKit类以使其更具可测试性。
• UI层具有与域实体不同的自己的视图实体。

域层

• 业务逻辑层。
• 每个用例都是执行特定业务逻辑的可重用且独立的组件。
• 域层对其他层一无所知，只是从定义为协议的存储库中获取数据并返回结果。
• 域层具有其自己的域实体，不同于视图数据实体。

资料层

• 它使用存储库模式（+ info）。 基本上，存储库模式在数据源上添加了一个抽象层，用例从中获取数据。 使用存储库模式，您只需一个入口即可查询来自不同数据源（核心数据，领域，Web服务器等）的模型对象。
• 业务逻辑不应该知道数据来自何处。
• 数据层有自己的数据实体，与域实体不同。