编程思想-0x00架构

产生架构的原因?

1、代码均摊

将不同的代码进行分块,然后简历联系,低耦合、高内聚;

原则上:合理的App架构应该是合理分配每个类、结构体、方法、变量的存在都应该遵循单一职责的原则

2、便于测试

测试确保代码质量;

单元测试、性能测试、UI测试 对单个方法或界面进行测试。
合理解决了分配决定了各个测试能够各司其职、不重复、不遗漏,让测试效率和覆盖率达到最大。

3、具有易用性

确保App架构也可以保证他们能快速学习并适应。

常见的架构有:MVC(MVCS)、MVP、MVVM、VIPER ...

0x01 MVC [model-view-controller]

Model层:负责数据处理,包括网络数据和持久化数据的获取、加工等;

View层:负责处理界面绘制,展示数据,并对用户产生及哦啊胡反馈等;

Controller: 负责处理业务逻辑等。

MVC分为主动模式被动模式 —— 根据Model来划分

被动模式:不会主动将它的变化通知给View进行更新,而是由Controller更新View关于Model的变化; 而且只有Controller可以对Model进行更新;

主动模式:Model的修改会通知View更新,利用观察者模式:View为观察者,Model为被观察者。 在Web端,传统意义上的MVC是主动模式; 而在移动端,对数据变化频繁的场景,可以应用MVC的主动模式。

MVC被动模式
MVC主动模式

优点

代码量少:基于MVC上大量的逻辑和试图代码都集中在VC中,View和Model有严格区分,代码分配遵循一定原则

简单易懂:新手可以快速上手

缺点 —— 主要是视图层控制器层高度耦合造成的

1、代码过于集中:VC两部分高度耦合,它处理交互、视图更新、布局、Model数据获取、修改、导航等几乎所有的操作

2、难以进行测试:高度耦合,使得检测为主的单元测试需要配合特定试图才能够进行,让测试难度增大

3、难以扩展:VC中添加性功能要格外小心,高耦合容易出错。 View和VC高度耦合,可能会改动很大的代码

4、Model层过于简单:model层基本上只是定义几个属性,.m文件中基本上看不到代码

5、网络请求层无从安放:网络层如果放在model层, 其异步调用API请求会使得整个model层变得复杂;放在“”VC中, VC更加复杂。 缺点会被更加的放大。

小结:MVC代码分配过于笼统,对于任何一个雷,主要不是View或Model就会放到vc中,VC类耦合了视图和控制器。

MVCS

针对MVC的优化;

S【store】【service】
一般存储层(eg:CoreData)就是store;将它从Model或者vc中才分出来构建单独文件; MVC的网络可以放到S层,逼近网络请求获得数据,要进行缓存和持久化处理,所以放在数据层中也比较合理。

拆分出来,代码更加均衡,VC难以单元测试,通过数据层拆分了之后,整体架构的维护和扩展也起到了促进的作用。

0x01 MVP [model-view-presenter]

相比MVC, model功能一样
MVC中的View和Controller耦合在View类中
MVP View是单独的UIView/UIViewController, Presenter是单独的类。

MVP架构

MVP中的View层是单独的Class[UIView/UIViewController],它持有Presenter作为变量;
View接收到用户交互信息时,它会调用Presenter进行处理;
View层不包括任何业务逻辑代码,它只会将交互给Presenter, 并从Presenter中接收结果来更新自己。

View持有Presenter,所以Presenter中的View应该声明为weak或unowned,避免循环。

优点:解耦View和Controller之间的耦合,将View和Presenter区分得更加清楚。将业务划分更加精细

缺点:View所有的交互都传给Presenter处理,一旦项目功能增加了,View的代码和Presenter的代码将会增加。 相比MVC在VC一个文件里面就解决,MVC总代码量会增加。App维护成本和文件会增大。

0x02 MVVM - [model-viewmodel-view]

ViewModel: 提供数据、交互响应, 替换presenter

ViewModel一般扮演两个角色:
1)视图层的真正数据提供者

一般视图层展示的数据经常是一个或多个模型的属性组合。

eg: 微薄数据流界面,可能一个微薄用户模型有FirstName, LastName, status, post等多个属性; ViewModel就会将这些数据整合在一起,使得视图直接调用单个数据就能够展示索要的效果。

2)视图层的交互响应者

所有用户的及哦啊胡都会传递给ViewModel, ViewModel会一次更新视图层需要的属性,同时相应修改模型层的数据,这里依靠的是属性观察响应式架构; 这里是View和ViewModel关系,而MVC中的主动是View和Model的关系。

MVVM的模型

小结:ViewModel代替Presenter,增加了数据绑定的功能。

MVX的这三种架构的区别

M:Model模型层
V: View 视图层
C/P/VM: 中间层 Controller, Presenter,ViewModel

1)模型层几乎相同
三种架构的魔心从理论上说都是数据来源,没什么不同;

2)视图层在理论上都设计为被动,但是实际上略有不同

MVC:实际上,视图层和中间层高度耦合,几乎所有的操作都是统一由ViewController包办;理论上,视图层是淡村的UIView或UIViewController,只是负责UI的更新和交互,不涉及业务逻辑和模型更新; —— 实际上,MVP和MVVM的视图是实现了MVC理论期望,即为中间层严格分离。

MVP:视图层完全是被动的,单纯地把交互和更新传递给中间层

MVVM:视图层并不是完全被动, 它监视中间层的变化,一旦产生变化,则视图层会响应变化。

3) 中间层的设计是三种架构的核心差异
逻辑上:中间层的作用是连接视图层和模型层,用于处理交互、接受通知和完成数据更新;

MVC中间层Controller 持有视图和模型,主要起到组装和连接的作用;通过传递参数和实例变量直接完成所有操作

MVP中间层Presenter持有模型,在更新模型上与MVC中的Controller是一样的;但是它不用有视图,视图拥有中间层;中间层的工作流:从视图层接收交互传递更新模型;接受模型的通知,更新视图。 全部操作必须手动书写代码完成。

MVVM中间层View Model持有模型,在更新模型上与前两者相同,它完全独立于视图,视图层拥有中间层,通过绑定属性自动进行更新,全部操作由响应式逻辑框架自动完成。

优缺点
MVC的耦合度很高, 代码分配最不合理, 维护和扩展成本最高。 但是因为无需层级传递, 所以代码总量最少, 适合初学者理解和应用;

MVP和MVVM相似, 耦合度和代码分配都比较合理, 比较容易实现搞测试覆盖率。

MVP的缺点是视图层需要将所有的交互传递给中间层, 且要手动实现响应和更新, 所以总代码量远远超过MVVM。

MVVM 在响应和更新上, 通过响应式框架自动操作, 大大精简了代码量; 但是需要引入第三方响应式框架, 同时, 因为属性观察环环相扣, 调用栈很大, 所以Debug起来尤为痛苦;

三者都是以视图为驱动的架构;即为:以用户交互和试图更新为主要服务目标。

公共缺点:没有涉及到页面之间的跳转 —— 路由的设计

0x04 VIPER之间的各组件是如何交互的

关键词: 路由、interactor
五个组成部分:View、Interactor、Presenter、Enity、Router

VIPER架构

1)视图层(View):与MVP、MVVM视图层类似,它包含UI相关的一切操作;它接收用户的交互信息但并不处理,而是传递给展示层(Presenter)

2)展示层(Presenter):与MVP的presenter或MVVM的VM类似,对于它更加类似MVVM还是MVP,取决于是否引入响应式编程架构; Presenter 在这里只响应并处理视图层传来的交互操作请求,并不直接对数据源进行修改,这个与MVX中间层最大的区别;若是需要修改数据,展示层会向其持有的数据管理层(Interactor)发送请求, Interactor 会处理一切有关数据源的操作。 此外他还有路由了路由层(Router)

3)路由层 (Router):专门负责界面跳转和组件之间的切换;当App占用空间较小时候,Router负责页面跳转; 当APP占用空间较大的时候,不同的功能和业务会被拆分成不同的模块和组件,Router的作用就是在不同组件之间进行连接。 这就是MVX架构所忽略的部分;

4)数据管理层(Interactor):专门负责处理数据源信息, 包括你网络请求、数据传输、缓存、存储、生成实例等操作。 实际上, 之前中间层和模型层的一些逻辑被进一步剥离至此, 整个架构的逻辑也显得更加清晰。

5)型层(Entity):只拥有初始化方法和属性相关set/get方法, 与之前的Model层大同小异;

小结:由于分工明确, VIPER 层在代码分配、测试覆盖率上为所有架构之冠。而VIPER的缺点在于, 它依然与MVX架构一样, 是一个视图驱动的架构。同时VIPER由于分工精确, 不同的层级之间交互的代码很多, 总体代码量很大, 不适宜用在小型App中。

本文由mdnice多平台发布

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342

推荐阅读更多精彩内容