Swift中的项目架构MVVM

如果您一直在使用Model-View-Controller模式来构建Swift应用程序，这可能看起来很熟悉。

它代表Model-View-ViewModel

问题：

让我们从一个例子开始：

在上述程序中， MovieViewController完成加载其视图后，将执行网络请求。 它将此任务委托给MobileAPIService类，这是减少视图控制器职责的良好起点。

实现看起来不太复杂，这可能是正确的。 它有一些缺陷。 但是我们关心的是视图控制器为何负责发出网络请求？🤔确实， MobileAPIService可以帮助MovieViewController完成此任务，但是MovieViewController仍然知道它获取的电影来自后端。

您可能会争辩说，这些细节被MobileAPIService隐藏了，但这不是重点。

对于MovieViewController应该考虑以下几点 。

1. MovieViewController控制一个视图。
2. 除了API调用，本地数据库处理等其他处理外，它仅应用于UI呈现。
3. 它不应该知道电影从哪里来。
4. 它只需要询问要在其视图中显示的内容。
5. 它甚至不应该了解MobileAPIService。 更不用说它是如何工作的。
6. 在客户端程序（我们的案例MovieViewController ）中，必须有最少的代码，从而减少了错误。

不幸的是，我们没有在程序1.0中实现以上几点。

解决方案：

MVVM模式是MVC模式的稍微复杂一些的实现，请花一点时间来思考一下MVVM在上述实现中可能具有的优势。

与程序1.1相比，在程序1.0中的实现是如此简单，这可能是正确的。

MVC实现的ViewController还可以管理状态，newsList实例，MobileAPIService等。 这不是坏事还是好事，但是在MVVM中，它在ViewMode中隐藏了这些细节

MVVM实施 的 新变化：

1. MVVM模式在ViewModel中隐藏电影，状态， MobileAPIService详细信息。
2. 发现ViewController仅负责UI控件。
3. ViewController与一系列电影无关。 甚至不知道电影的来源，例如通过远程本地存储。 它们可能来自由核心数据SQLite管理的后端或本地存储。
4. 单元测试和可测试性得到改善。
5. 它将这些细节隐藏在ViewModel中

是什么使Model-View-ViewModel很棒

1. 体验MVVM的第一个好处是可以从视图控制器中删除多少代码。
2. 视图模型是位于模型层和控制器层之间的轻型对象。
3. 您的视图控制器不会直接与应用程序的模型层通信。 视图模型为视图控制器提供数据，并提供与模型层交互的界面。

单元测试

通过移动业务逻辑（数据操纵）来查看模型。 测试我们的应用程序更加容易。 测试视图模型很容易，因为它不包含客户端程序引用。

视图控制器不依赖于模型层，因此易于测试。

任务分离

通过添加视图模型，视图模型将数据层的数据转换为视图使用的某种内容（例如模型）。

视图控制器不负责此任务管理。

请找到完整的源代码

shantaramk / MVVM
迅速开发MVVM模式5。通过在GitHub上创建一个帐户，为shantaramk / MVVM开发做出了贡献。 github.com