iOS中的架构模式

在最近的过去，我一直在花一些时间来了解大多数软件开发人员所犯的菜鸟错误。 老实说，我经常被召唤。

但是，我最内gui的一个错误是，在开始项目之前没有计划。 这对我们最好的人来说已经发生了。 从第一天开始，您就可以开始这个令人惊叹的全新闪亮项目。 这个项目的成功，潮起潮落可以这么说。 通常，这种兴奋会击中应该做出合理决策的大脑部分。 因此，您该怎么做，您会立即开始编写代码。 五天后，该项目开始呈螺旋式下降。 您开始想象自己对这个项目的判断有误。 毕竟，这可能不是一个很酷的项目，也许这是一个很好的旧诱饵和转换案例。 但是事实是，您就是问题所在。 这不是项目，从来没有。 该项目保持不变，是您改变了。 💔如果您不计划，那么很可能会迷失其中。 兴奋消散之后，您将得到的只是意大利面条代码。 然后，您很可能会放弃它，或者更糟糕的是，仍然编写可怕的，没有灵感的代码。 现在我们已经大声疾呼了，让我们看一下要计划的最重要的事情之一。 所有冰雹建筑模式！ 👯

您问什么架构模式？ 它是对常见问题的通用可重用解决方案。

你为什么要关心它？ 架构模式使您和您的团队成员的工作更加轻松。 由于关注点分离，因此更容易调试和浏览代码库。

哇！ 那是很多单词，没有代码。 现在您仍然在这里，我将为您提供一些代码。 🎉

聊够了，给我看看代码！！！

MVC

我们将从这个非常常见但被误解的模式start开始。 MVC已经存在了很长时间。 您知道MVC，这就是隔壁的低维护模式。 如果您已经编写了iOS代码，则可能使用了MVC模式。 这是构建iOS SDK的模式。 这种模式将所有代码分为模型，视图和控制器。

模型; 这是数据所在的位置。 它负责持久性，建模对象和解析。

视图; 这负责与用户进行交互的所有内容，即在屏幕上看到的内容，例如标签和文本字段。

控制器; 这在模型和视图之间进行中介。

MVC示例

如上所示，该模型基本上是对数据进行建模。 在此示例中，它将膳食数据项描述为具有两个属性。

在此示例中，视图和视图控制器紧密耦合。 如果有人要问MVC中的视图和视图控制器之间有什么区别，我会说我不确定。 因此，MVC无法分离关注点 。 由于视图控制器趋于庞大并且几乎无法导航，因此它被命名为Massive View Controller。

但是，MVC在构建小型项目时非常完美。 这是因为它很容易学习。 当项目不是很复杂时，使用MVC以外的模式可能会被认为是过度设计。

MVVM

MVVM基本上是MVC，只是需要更精细的关注点分离。 它的缩写代表模型，视图和视图模型。 MVVM是MVC的爱好者，也是更高维护成本的朋友。

模型 ; 就像在MVC中那样处理数据逻辑

查看 ; 就像在MVC中一样。 视图控制器被称为视图。

ViewModel ; 它负责以应呈现的形式将数据对象从模型公开到视图。

MVVM示例

MVVM复古吗？

MVVM如何工作？

视图控制器将事件发送到视图模型。
在MVVM中，视图模型对视图控制器一无所知。 这使其易于重用。 它也与视图完全分开，因此测试非常容易，因为不必模拟视图。

为什么选择MVVM？

Mvvm肯定更加分散，因此更易于测试。

MVVM -C

MVVM模式令人惊奇，但它有一个缺点。 它没有考虑应用程序路由方面。

应用程序路由 ？ 假设您有一个具有多个屏幕的应用程序来处理从一个屏幕到另一个屏幕的移动，则应用程序路由会处理此流程。 输入MVVM -C，基本上是带有发亮因素的MVVM，它是一个闪亮的协调器。 协调器处理应用程序的流程和导航。

MVVM -C示例

复古风

为什么选择MVVM -C？ 尽管MVVM解决了MVC引入的许多耦合问题，但在视图模型中引入导航功能的那一刻，就再次引入了耦合问题。

MVVM -C如何工作？ 它的工作原理与MVVM完全相同，只是我们添加了协调器来解决导航问题。

有好处吗？

更好地分离关注点–在这里，我们有四个单独的实体，每个实体执行一项特定任务。

易于测试； 将导航与视图模型隔离意味着视图模型变得更加易于测试。

可重用的代码； 当我们从模型中消除导航时，我们可以重用代码

动态导航； 从不同位置注入各种视图非常容易。 协调员不知道发生了什么或将会发生什么。 因此，我们可以将其放置在我们想要的任何位置。

最有价值球员

MVP是模型，视图和演示者的缩写。

模型; 它包含封装应用程序数据部分的业务逻辑和业务规则。

视图; 它由UIKit的元素组成，基本上就是我们在屏幕上进行交互的内容。

主持人; 这具有处理用户交互的逻辑。 它与模型层通信，将数据转换为UI友好格式。

MVP示例

当我第一次阅读有关内容时，我意识到它与MVVM非常相似。 像MVP一样，在MVVM中，视图UIKit逻辑和视图业务逻辑分开，并将其放入另一个文件中。 似乎演示者是具有不同名称的视图模型。 🐺明白了，披着羊皮的狼？ 😆但是，要注意的一个主要区别是，与MVVM不同，应用程序中处理业务逻辑（演示者）的部分对视图有一定了解。 在MVVM中，视图模型完全愚蠢，不了解视图。

毒蛇

Viper是唯一不采用MV（X）模式的架构模式。 毒蛇有五层，做了更多的关注点分离。 Viper缩写为View，Interactor，presenter，entity和router。

视图; 这由UIKit元素组成。 这些不包含任何业务逻辑。

交互器 这包含与数据关联的业务逻辑。 基本上就是从模型层获取数据的原因。

主持人; 这包含UI业务逻辑。 它将数据准备为UI所需的格式。 它与所有其他层通信。

实体； 这些基本上是数据对象

路由器; 这负责模块之间的交互。

我发现使用游乐场片段展示毒蛇有点困难，因为它很大。 但是，有关如何使用Viper的在线资源很多。

复古风

为什么要毒蛇？

毒蛇架构的优势在于可分发性和可测试性 。 正如您可能已经观察到的，它具有最大的权力分离。 分布更多意味着更容易测试。

建筑之战？ ⚔️

当使用不同的体系结构时，重要的是不要问哪种才是最好的，而哪种才是最适合您的情况。 这意味着您将使用最简单的方法。 例如，如果我正在构建一个简单的新闻应用程序，则使用MVC将很有意义。 但是，如果我的应用程序扩展了规模，并且引入了其他功能（例如登录），则将有助于引入更多关注点分离。 因此，最佳架构模式的问题并没有真正的答案。 如果您发现自己在问这个问题，请退后一步，重新评估您的情况。

如果您从我的沉思中学习到一些东西，或者喜欢我的la脚/不存在的笑话，请为此拍手。 我希望其他人成为我的学习网络的一部分。