iOS架构回顾-2021-02-02

MVC

image.png

image.png

• 模型Model和视图View之间不应该直接通信；他们之间是双黄线，禁止通行；

M向C通信

• 从网络取得的数据，一般保存在M当中；大多数情况，使用block的方式通知C；

• 也可以通过发送Notification的方式高速C，不过这种方式太离散，用的不多；

• KVO是一种观察者模式，一般情况都是C观察某一个属性；当其他类修改这个属性的时候，C就知道了。这种场景有，不过也不是很多；

C向V通信

• 代码写界面，View一般是C的一个成员；通过M得到数据之后，直接View的属性就可以了。故事版画界面，会通过输出口outlet的方式，C可以设置View的属性。

V向C通信

比较常见的就是按钮，一般是在按钮上设置action-target的方式，得到用户的操作。这是一种事件响应机制。

C向M通信

C得到用户的action，直接修改update相应的M就可以了。如果需要通知后台，就发起一个网络请求就好了。

特点

整个过程，哪一步都离不开C，这就导致C非常忙碌，非常复杂。

iOS的MVC框架

MVP

image.png

视图（View）：用户界面
模型（Model）：数据存储
展示器（Presenter）：数据处理，业务逻辑。

在Presenter中根本没有和布局有关的代码，但是它却负责更新View的数据和状态。

MVP在Android中用得更多。

MVVM

image.png

视图（View）：用户界面
模型（Model）：数据存储
ViewModel：数据请求，数据处理，业务逻辑。

image.png

• 在MVC的基础上，把C拆出一个ViewModel专门负责数据处理的事情，就是MVVM。View <-> C <-> ViewModel <-> Model；

• MVVM和MVP很像，VM的作用和P类似；

• MVVM在iOS中用得比较多；MVP在Android中用得比较多；

• ViewController 持有 View 和 ViewModel，当 VC 初始化时，会让 ViewModel 去取数据，简单来说就是调用 VM 的某个获取数据的方法。

• Controller夹在View和ViewModel之间做的其中一个主要事情就是将View和ViewModel进行绑定。在逻辑上，Controller知道应当展示哪个View，Controller也知道应当使用哪个ViewModel，然而View和ViewModel它们之间是互相不知道的，所以Controller就负责控制他们的绑定关系

• 为了让View和ViewModel之间能够有比较松散的绑定关系，于是我们使用ReactiveCocoa，因为苹果本身并没有提供一个比较适合这种情况的绑定方法。

• iOS领域里KVO，Notification，block，delegate和target-action都可以用来做数据通信，从而来实现绑定，但都不如ReactiveCocoa提供的RACSignal来的优雅。

VIPER

image.png

• VIPER 可以是视图 (View)，交互器 (Interactor)，展示器 (Presenter)，实体 (Entity) 以及路由 (Router) 的首字母缩写。

视图（View）：根据展示器的要求显示界面，并将用户输入反馈给展示器。
交互器（Interactor）：包含由用例指定的业务逻辑。
展示器（Presenter）：包含为显示（从交互器接受的内容）做的准备工作的相关视图逻辑，并对用户输入进行反馈（从交互器获取新数据）。
实体（Entity）：包含交互器要使用的基本模型对象。
路由（Router）：包含用来描述屏幕显示和显示顺序的导航逻辑。

• 实际的例子：自己并没有用过这个模式，但是接手的项目中却有人用了这个模式。

image.png

这么一个页面，用了好多类来实现。
职责划分是更细了，但是文件数量多了很多。同样的，相互间的调用也增多了。

参考文章

iOS架构模式(MVC/MVCS/MVP/MVVM/VIPER)

后记

这么多的架构模式一圈看下来，就像是 “XXX从入门到放弃”那样，到最后，还是回到了起点MVC。
MVVM在自己的项目里用过，ReactiveCocoa也引入了；能用起来，双向绑定也还不错。不过，最后都会不自觉地问了一句：有必要吗？
很多页面都是一次性的，独立出一个VM出来，并没有多少复用，但是文件数量却增加好多（一下子就是2个.m和.h）；
复杂度也没有减少，只是从Controller转移到了VM中；
并且由于多了一个角色，在Controller中很简单直接的事情，却要绕好几个弯。比如跳转，VM中没有self.navigationController啊。

所以，后来，反而会优先考虑使用MVC；
太复杂了，就考虑分隔组件；
也可以考虑独立出一些专用的工具；
或者引入各种Helper，Adapter等辅助类，照样能达到Controller瘦身的目的；
更进一步，可以考虑封装成各种framework，有界面无界面都可以；组件或者独立的业务都可以，比如登录，扫一扫，手势密码等等，都可以考虑封装成独立的framework
framework也不一定非要用CocoaPods，在自己的工程中，以Target的方式封装framework，不需要打包发布那些麻烦事，使用起来跟“独立的文件夹”一样方便。

绕了一大圈，感觉又回来了。但是现在的MVC和一开始的又有点不一样。更确切地说是“MVC+组件化+framework封装”