VIPER体系结构iOS Swift
好的，这是另一篇解释iOS Swift的VIPER架构的文章。
这是什么意思，为什么我们要关心VIPER？它比Clean Swift作为VIP更好和更容易，它们真的彼此不同吗？
本文结尾处的示例项目。
让我们从两者之间的一个小比较开始：
VIP和VIPER具有相同的文件结构，即使省略中也没有提到ER，它的确有一个实体“模型”和一个路由器“线框”，那又是什么呢？
VIP是一种单向流，它来自：
UI->视图->交互器->演示者->返回视图。
VIPER是多向流，来自：
UI->视图->演示者->交互器->演示者->返回视图。
那么，为什么我认为VIPER比VIP或Clean Swift更容易维护？
有人认为实体是模块的主要模型，而我个人认为实体是实际模型的字符串表示形式。
实体在Interactor中进行映射，并传递给Presenter进行格式化，因此，应该在模块周围流动的对象是Entity，并且没有ViewModel或实际Model在周围流动。
Interactor知道该实体，并将其传递给Presenter，该Presenter将处理格式并将实体类型作为视图的形式传递给视图。
VIPER非常容易实现单一责任原则。
具有ViewModel + Entity只是违反了DRY和KISS原则。
实体是VIPER元素，不应与模型混淆。
因此，我和我的同事在一个Generator上工作，它将准备好正确处理流，而无需麻烦地创建ViewModels，或者让View处理与交互器的路由或事件，因为viper的格式应为：
视图了解Presenter。
演示者了解View，Interactor和Router。
Interactor知道Presenter和Entity。
这是一个演示项目，它以简单的方式实现VIPER设计模式，从而可以实现可测试性，可维护性和可扩展性。
有些人更喜欢Presenter应该格式化传递给View的数据，我实际上不同意这个概念，因为众所周知，Interactor 操纵 Entity。
Kaakati / CoolBlue-iOS
人们可以在GitHub上构建软件。 超过2千8百万的人使用GitHub来发现，发掘和贡献超过……
github.com
上面的示例是使用生成器构建的，该生成器会将您的文件作为UI组件，作为ViewController的Viewer，演示者，路由器，交互器和实体分为UI。