我们喜欢软件架构模式

我们作为世界上的移动开发人员,通常会使用许多很酷的软件体系结构模式,通常都包含字母M和V(MVC,MVP,MVVM,VIPER),这会对新编写应用程序的人造成很大的挑战或困扰。 让人们重新关注这种模式应该做什么也很好。

有什么问题?

从头决定如何在大型应用程序中构建每个组件是多余的。 您面向用户的组件都将获取数据,然后根据该数据在屏幕上绘制并接收用户交互。 我们喜欢MVC / MVP和MVVM之类的设计模式或概念框架,因为它们提供了模型,视图和控制器之类的抽象对象来划分职责,并确保组件井井有条。

但是我想做更多的事情!

大多数时候,您将需要分离其他对象来处理获取数据,处理数据以及处理用户交互的后果。 最后,对这些背景对象的引用由与视图相关的组件保留。

当您需要分开职责,想要重用组件并帮助允许访问与视图无关的状态(例如,您有多少消息或是否已登录)时,可以这样做。 网络和数据持久性是经常需要分开的职责的示例。

处理这些组件的状态和状态,尤其是当它们可能在应用程序的多个页面之间共享时,变得很困难。

毒蛇巢

VIPER是一种比MVC更进一步的体系结构,它为更复杂的应用程序指定了各种额外的组件。 由显示内容并接收用户交互的视图 ,分析数据并确定要显示的内容的交互器演示者 ,代表数据的实体以及路由器组成 ,以处理已显示的页面并进入新的页面。 这是一个很好的框架,请在此处阅读。

冲床

通常情况下,各个组件的状态会耦合在一起,这意味着您必须在不模拟整个应用程序或某些特定用户旅程的情况下,才能测试应用程序某一部分会发生的情况(“该错误仅在我尝试下达一个订单并取消它,然后尝试注销”-希望这永远不是真的)。 您还失去了对应用程序进行安全的结构更改的能力,因为您不知道后果将达到多远。

本质上,在应用程序的整个生命周期中,拥有一个良好的组件设计系统并实施通用样式,可以创建出更快地编写(希望),更易于维护(更易于理解和更改)并保持脱钩(也称为可测试)。

有关

首先编写测试会更好
苹果的MVC不是MVC
协调员,现在听起来很花哨