架构模式的一些学习和思考

前言

最近读到罗琦的架构分享:VIP模式,感觉是个"性价比"非常高的架构模式.在此记录一些学习和思考.

当前模式

MVC的诟病很清晰,所以都在寻找更好的模式.后来的MVP,并没有解决MVC的问题.然后MVVM,乃至更多的模式.我个人觉得似乎都或多或少有一些缺陷.而我目前沿用单项MVVM+P的模式,在VIP模式下,似乎通畅了不少.

MVC作为苹果推荐模式,controller代码爆炸,无法测试等诟病很清晰.

MVP把controller作为presenter,并没有实际改善MVC中C的问题.

MVVM很热,有RAC支持,能够非常好的解决问题,但是我不喜欢.

其余的模式,例如视频中提到的viper模式,不太常见,理解不深.借用视频中的话:Over Design

MVVM

MVVM = Model + View + ViewModel
Model为数据存储,也就是各种property
View为显示,各种UIView和其subclass的组合
ViewModel为粘合剂.我所理解的为:就是以前的business.

我不喜欢的原因是,MVVM还具备一个特性:双向性.也就是说View的变化,会反映在ViewMode上;ViewModel变化,也会导致View变化.
为了实现这个特性,一般依赖RAC(KVO).

我不成熟的理解:设计模式是对工作(代码)的拆分与组合,以达到"高内聚,低耦合"的目的,而并不希望它依赖某个东西.因为学习并且维护某个依赖项是有成本的.

RAC的优势极度明显,虽也有一定的劣势:

  • 学习曲线(其实这不算是问题,通过学习解决)
  • 大量的KVO,效率问题(无法解决,但是效率瓶颈一般不在这里)
  • 调用栈长(通过经验解决)

但是这并不是最主要的原因.最主要的原因是RAC是改变的一个编程思想:响应式.包括信号,观察,订阅等.如果要使用RAC,那么是否整个工程都要改变思想呢?

朋友所在的某拥有2亿+用户的知名创业公司,曾经为了引入RAC,花了一个多月的时间将工程整体改造.

VIP

看到这个模式,感觉把我自己采用的模式进行了一个非常不错的升级.通过对项目的初步实验和改造,以下为我的学习和理解.

VIP = View + Interactor + Presenter

换个说法可以理解为依赖Protocol的,单向的ViewController + Model + View + Fetcher(Interactor) + Transformer(Presenter)

主要依赖2个Protocol(视频中是3个):
1.FetcherOutput
2.TransformerOutput
意思是,当fetcher去获取(fetch)数据完成后,通过FetcherOutput进行数据输出;同理,当Transformer进行数据转换(transform)后,也通过代理进行数据输出.

总体来看,因为是单向的,所以不存在双向数据绑定的问题.由ViewController在合适的时机(生命周期/点击按钮等),通过fetcher调用数据.调用成功后,此时的数据为原始数据.将原始数据交付给delegate,既:transformer.通过transformer进行数据运算和转换(dict/model)后,交给delegate进行displayer.当然这里的delegate即为ViewController本身.

伪代码:

在ViewController中:

- (void)viewDidLoad {
 [self setupVIP];
 [self.datafetcher fetchData];
}

- (void)setupVIP {
 self.fetcher = [Fetcher new];
 self.transformer = [Transformer new];

//设置fetcher的output代理
 self.fetcher.output = self.transformer;
//设置transformer的output代理
 self.transformer.output = self;
}

//transformer的代理方法:display
- (void)displayData:(id)data {
 //display by tableview,etc...
}

在Fetcher中:

- (void)fetchData {
 /*
 在视频中专门为获取数据封装了一个worker类,目的是可以方便的切换数据来源.
 没有需求的话或许也可以简化.
 */
 xxxx (fetch data from api/db)
 [self.dataformatter tranformData:data];
}

在Transformer中:

- (void)tranformData:(id)data {
 xxxx(transform data)
 [self.displayer displayData:data]
}

感受

设计模式最终是为了更好的维护项目.从实际出发我觉得最好能达到几个效果.

  • 团队基本能写出风格一致的代码,容易修改/维护
  • 新人能够迅速的理解并且加入
  • 接手的人能够快速的接手并且修改/维护
  • 能够更加容易的进行测试

我称之为"性价比",VIP模式我个人认为"性价比"还蛮高的.我会继续学习和使用,也推荐大家测试一番.

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

推荐阅读更多精彩内容