VIPER 架构

Posted 2023-05-13

参考技术A

架构优点 ：
一个VIPER模块可以看做是一个独立的组件，可以被单独封装成一个库，app就负责将各个模块连接起来，实现了模块间的解耦。当业务需求更改，只需要修改 交互器 ，基本上就可以实现了。

View ：视图层，平时用的 UIViewController 。主要负责视图的显示、布局，用户事件的接受以及转发，简单的显示逻辑。

Interactor ：交互器，核心部分。主要负责交互的工作，业务逻辑，网络请求，数据持久化处理，这一层获取到是最原始的数据，经过解析，处理成 视图层 可以直接使用数据。

Presenter ：展示器。主要解析交互器给的数据，和调用 视图层 的接口。拥有 视图层 相关的各种状态和配置，执行 交互器 的业务逻辑，调用 视图层 的接口把数据直接展示出来。

Entity :：实体模型对象，平时用的 model

Router ：路由器。主要负责跳转页面。依赖注入对应的目的模块，减少了模块间的耦合。

在具有 VIPER 架构的应用程序上更新 NSManagedObject

【中文标题】在具有 VIPER 架构的应用程序上更新 NSManagedObject

【英文标题】：Update NSManagedObject on a app with VIPER architecture

【发布时间】：2016-04-14 17:36:23

【问题描述】：

在执行 VIPER 架构的应用上，建议使用 NSObject 而不是 NSManagedObject（交互器）来处理实体。因此 NSManagedObject 在 PONSO 中被“转换”以使用。 问题是，如果我修改了 PONSO 中的属性，我该如何更新 Core Data？

谢谢。

【参考方案1】：

只需使用NSManagedObject 而不是NSObject。这个建议不能从字面上理解。无论如何，NSManagedObject 是NSObject 的直接后代，因此对于所有实际用途来说，它都一样好。

顺便说一句，VIPER 是一种通用的架构理念，由于其文件和功能的粒度过大而没有得到太多关注。我建议您通过围绕这些控制器更有效地构建代码来减少“大规模视图控制器”问题，并使用 VIPER 作为灵感的良好来源。

【讨论】：

这不是一个好主意，因为 VIPER 背后的想法之一是将数据持久性实现与应用程序的其余部分分开。如果你现在开始传递 NSManagedObjects，你的所有代码都依赖于 CoreData，你也会遇到@Arkadi 提到的问题

只有@Arkadi 是错误的。 Core Data 是线程安全的，因为它是 iOS 上的 de facto 持久性标准，我建议的解决方案不会妨碍关注点分离，同时利用 Apple 的 API 来简化和提高性能.

我最近非常频繁地使用 CoreData，我可以确保 CoreData 在错误的线程上使用时仍然偶尔崩溃；偶尔我的意思是崩溃发生在百万分之一的操作中，但它们确实发生了。因此，您需要将每个操作包装在同步执行块中。此外，即使 CoreData 很棒，另一种数据库解决方案也可能是合适的；尤其是在需要同步到 Android 或 Windows 时。

【参考方案2】：

这是一个非常糟糕的主意。如果您在应用程序中使用任何异步代码元素并且我们大多数人都这样做，您应该知道 nsmanagedoject 不是线程安全的传递。你需要重新考虑你的方法。如果您使用核心数据支持的应用程序，那么您可以将 managedobjectid 存储在 ponso 中并使用它来更新数据库，同时在数据库更改后触发 ui 刷新