您的位置:时时app平台注册网站 > 编程知识 > iOS MVC、MVP、MVVM时时app平台注册网站

iOS MVC、MVP、MVVM时时app平台注册网站

2019-09-14 00:42

什么人能教教小编用markdown归入图片怎么设置图片大小?

时时app平台注册网站 1通信图

1)MVP情势下的八个特色的深入分析:
  • 职务均摊 -- 大家将最关键的任务划分到 Presenter 和 Model,而 View 的机能非常少;
  • 可测验性 -- 相当好,由于贰个功效轻巧的 View 层,所以测验大大多事务逻辑也变得轻便;
  • 易用性 -- 代码量比 MVC 形式的大,但同期 MVP 的概念却百般清楚。

时时app平台注册网站 2图片来源于网络.png

ViewModel中创立好诉求的实信号RACSignal, Controller中订阅那几个信号,在ViewModel达成央浼后订阅者调用sendNext:方法,Controller里面订阅时写的block就收下回调了。

3)标准的MVP设计格局:

1、Model 层应该不只有是创立一个数额对象,还应该包蕴互连网央浼,以及数据 SQLite 的 CRUD 操作(比方 iOS 平台,一般以 FMDB 框架直接操作 sql,或然用 CoreData) 。一般可以将数据对象是不是必要缓存设计成贰个字段 isCache,只怕针对全体项目设计二个开存款和储蓄关,决定一切项目是或不是须求多少缓存。大家广阔的新闻类 App,在离线的时候看看的数据,都以做了缓存管理的。举例部分金融类的 App,实时性比较高,是不做缓存的。

2、View 层比较轻便明,正是 View 的一些包装、重用。在一款精心设计过的 App 里面,应该有过多 View 是能够打包重用的。譬喻一些谈得来的 TableViewCell,本身布署的 Button,一些 View(包罗部分子 View,UI 精心设计过,在品种里多处出现的)等等。

3、Presenter 层并不涉及多少对象的网络须要和 SQLite 操作,只是 Model 层和 View 层的一个桥梁。Presenter 层就不一定太臃肿,轻松看懂。一些大的 App,或因为上线时间相当久了,经历过无数程序员的修补,或因前期并未有做好架构,以致于张开一个类,几千行的代码,瞅着协和都晕。

时时app平台注册网站 3table view.png

Demo地址:

二、MVP

  • 从字面意思来精晓,MVP即Modal View Presenter(模型 视图 和煦器),MVP达成了Cocoa的MVC的愿景。MVP的和谐器Presenter并不曾对ViewController的申明周期做任何变动,由此View能够很轻便的被模仿出来。在Presenter中向来未曾和布局有关的代码,可是它却承担更新View的数量和处境。

  • MVP 是首先个如何和谐解合八个实际分离的层系的架构方式,既然大家不指望 View 涉及到 Model,那么在展现的 View Controller(其实正是View)中处理这种和睦的逻辑就是不得法的,由此大家必要在其他地点来做那个事业。举例,大家得以做依据整个 App 范围内的路由服务,由它来承担执行和睦任务,以及 View 到 View 的来得。这一个出现同期必须管理的难题不止是在 MVP 方式中,同时也设有于以下集中方案中。

MVC和MVP的分别正是,在MVP中M和V未有平昔通讯。

时时app平台注册网站 4纯手打.png

M=Model, V=V C, VM = ViewModel. 为啥会叫ViewModel?

三、MVVM

  • 从字面意思来通晓,MVVM 即 Modal View ViewModel(模型 视图 视图模型)。MVC 是贰个用来组织代码的尊贵范式,也是创设 iOS App 的专门的职业情势。Apple 以致是那般说的。在 MVC 下,全部的目的被比物连类为二个model,三个 view,或七个 controller。Model 持有数量,View 突显与顾客交互的界面,而 View Controller 调节 Model 和 View 之间的互相。但是,随着模块的迭代大家进一步开掘 MVC 自个儿存在着广大相差。由此,MVVM 从别的使用而出,在 iOS 中事后大家全然将事情逻辑加以区分并选拔那套思想。在 MVVM 中她的设计思路和 MVC 很像。它正式标准了视图和调整器紧耦合的属性,并引进新的零部件 ViewModel。别的,它还应该有像禁锢版本的 MVP 那样的绑定成效,但以此绑定不是在 View 和 Model 之间而是在 View 和 ViewModel 之间。

3.在View里面描述好xib,然后定义item那几个性子,并把各子控件拖好线,重写item这么些性子的getter方法(因为在调整器中给item属性赋值时候就能够调用那一个点子), 在那个setter方法中用那么些item的一一属性来给View的子控件赋值, 到达把数据呈今后UI分界面上的指标---轻松的话正是在View里面得到Model数据,把多少显示在View上

在iOS开采中,UIKIt框架是将调整器ControllerView开展绑定了的,各样调节器都有View指标,代码加多UI子控件细节大概在xib与storyboard中子视图能够一向与controller进行关联,都会促成调节器中难以制止相当多相应View去担任的UI子控件细节管理放在了调节器Controller里面;而在Controller其间自个儿要管理的乞求、调控器生命周期函数要拍卖的事务相当多的气象下,调整器就变得很臃肿。实际上这些设计模式在iOS中为:M-VC

2)iOS MVP 示意图:

iOS MVP 示意图.png

  • 就 MVP 来说,UIViewController 的子类实际上就是 Views 而不是Presenters。那点分别使得这种格局的可测量试验性获得了庞然大物的拉长,付出的代价是支付进度的一些消沉,因为必供给做一些手动的数量和事件绑定。

  • 再有一对别样形态的 MVP -- 监察和控制调整器的 MVP。那个变体包括了 View 和 Model 之间的直白绑定,不过 Presenter 如故来保管来自 View 的动作事件,同不经常候也能独当一面临 View 的翻新。

1.在Model里面定义属性,用来保存互连网数据

MVVM的双向绑定

5)MVP的问题
  • 鉴于对视图的渲染放在了Presenter中,所以视图和Persenter的相互会超负荷频仍。
  • 再有一点点你须求理解,尽管Presenter过多地渲染了视图,往往会使得它与一定的视图的 联系过于紧凑。一旦视图供给更动,那么 Presenter也亟需改造了。譬如说,原来用来呈现Html的Presenter现在也需求用于彰显Pdf了,那么视图很有希望也亟需更换。

在编程世界中间大家都领悟一句话: 高内聚,低耦合

1. 实在支出中的做法:让Controller具备View和ViewModel属性,VM具有Model属性;Controller可能View来收取ViewModel发送的Model改动的通报

2. 客商的操作点击可能Controller的视图生命周期里面让ViewModel去实施乞求,诉求达成后ViewModel将赶回数据模型化并保留,进而立异了Model;Controller和View是属于V部分,即完成V改造M。借使没有供给央浼,那平昔退换Model正是了。

3. 第2步中的Model的更动,VM是精晓的,只要求Model改造后发一个公告;Controller或View接收到通告后(一般是Controller先接收再赋值给View),依据那一个新Model去改换视图就完事了M更动V

iOS MVC 示意图:

MVC.png

  • 1)Model 和 View 永久不可能相互通讯,只好通过 Controller 传递。
  • 2)Controller 能够直接与 Model 对话(读写调用 Model),Model 通过 Notification 和 KVO 机制与 Controller 间接通信。
  • 3)Controller 能够向来与 View 对话,通过 outlet,直接操作 View,outlet 直接对应到 View 中的控件,View 通过 action 向 Controller 报告事件的产生(如客商 Touch 作者了)。Controller 是 View 的直接数据源(数据很恐怕是 Controller 从 Model 中拿走并经过加工了)。Controller 是 View 的代办(delegate),以三头View 与 Controller。
  • 高内聚,便是指尽量让多少个类依然三个艺术它非常去管理八个政工,对外只提供多个接口,内部具体哪些促成无需告诉外界.
  • 低耦合,便是减掉类与类之间互相的依附,裁减代码的凌犯性,当改换一个类中的贰个东西时候,不须求另多少个类中也大批量改.

应用RAC(RactiveCocoa)框架达成绑定可以轻便到一句话归纳:

MVC自己不足

1)MVC 在切切实实应用中的不足:

  • 在 MVC 形式中 view 将客商交互布告给调控器。view 的调控器通过创新Model 来反应意况的改造。Model(平时接纳Key-Value-Observation)公告调节器来更新他们肩负的 view。大多数 iOS 应用程序的代码应用这种艺术来公司。

2)愈发笨重的 Controller:

  • 在观念的 app 中模型数据一般都很简短,不关乎到复杂的事情数据逻辑管理,客商端支出受限于它自个儿运行的的平台终端,这点尘埃落定使移动端不像 PC 前端这样能够管理多量的复杂性的职业场景。可是随着移动平台的各种长远,我们只可以思考这么些标题。守旧的 Model 数据大致来源于互联网数据,获得网络数据后客商端要做的事情就是将数据直接依照顺序画在分界面上。随着事情的越来越来的深远,大家依附的 service 服务大概在差不离年华不可能第临时间知足顾客端须求的数目要求,移动端愈发的要自行处理一部分逻辑总结操作。这些时刻一惯的做法是在调节器中管理,最后促成了调整器成了垃圾箱,更加的不行维护。
  • 调整器 Controller 是 app 的 “胶水代码”,和谐模型和视图之间的有着交互。控制器负担管理他们所独具的视图的视图档次结构,还要响应视图的 loading、appearing、disappearing 等等,同一时候往往也会充满大家不愿揭破的 Model 的模型逻辑以及不愿揭穿给视图的事体逻辑。那引出了首个有关 MVC 的难点...
  • 视图 view 平日是 UIKit控件(component,这里依据习贯译为控件)可能编码定义的 UIKit控件的聚合。步向 .xib 大概 Storyboard 会发掘二个 app、Button、Label 都以由那个可视化的和可相互的控件组成。View 不应当一向援用Model,况且只是经过 IBAction 事件引用controller。业务逻辑很料定不放入 view,视图本人并未有其余专门的学业。
  • 厚重的 View Controller 由于大气的代码被放进 viewcontroller,导致他们变的非常臃肿。在 iOS 中有些 view controller 里连连点不清行代码的事并非破天荒的。那一个超重 app 的卓越意况满含:厚重的 View Controller 很难保险(由于其强大的局面);饱含几13个天性,使她们的景况难以处理;遵从很多商业事务(protocol),导致协议的响应代码和 controller 的逻辑代码混淆在协同。
  • 沉甸甸的 view controller 很难测量检验,不管是手动测验恐怕使用单元测量检验,因为有太多只怕的意况。将代码分解成越来越小的四个模块平时是件善事。
    3)太过火轻量级的 Model:
  • 早先时代的 Model 层,其实正是假设数占领几特性子,就定义几个性格,ARC 布满现在我们在 Model 层的落实公文中好多看不到代码(无需再手动管理释放变量,Model 既未有复杂的作业管理,也绝非对象的组织,基本上 .m 文件中的代码分布是空的);同不经常间与调控器的代码越来厚重产生明显的反差,那曾经令人不由得对现成的开拓设计构思有所疑虑。

4)错失的互联网逻辑:

  • 苹果应用的 MVC 的概念是这般说的:全数的指标都足以被归类为一个Model,三个view,或是二个调整器。就那一个,那么把网络代码放哪儿?和贰个 API 通讯的代码应该献身哪个地方?
  • 您恐怕试着把它位于 Model 对象里,可是也会很棘手,因为互连网调用应该采纳异步,这样只要二个互连网央浼比全体它的 Model 生命周期越来越长,事情将变的目不暇接。显然也不应该把网络代码放在 view 里,由此只剩余调控器了。那无差异是个坏主意,因为那加剧了沉重调节器的主题材料。那么相应放在那里吗?显然MVC 的 3 大组件根本没有符合放那些代码的地方。

5)比较糟糕的可测验性:

  • MVC 的另三个大难题是,它不鼓励开辟职员编写单元测验。由于调节器混合了视图管理逻辑和业务逻辑,分离那几个成分的单元测量试验成了二个劳碌的职务。大相当多人挑选忽略那么些职责,那正是不做其他测量检验。
  • 上文提到了调控器能够管理视图的档次结构;调节器有多少个 “view” 属性,何况能够透过 IBOutlet 访问视图的别样子视图。当有无数 outlet 时那样做正确于扩展,在某种意义上,最佳不要采用子视图调节器(child view controller)来扶助管理子视图。在此处有多少个模糊的科班,就如从未人能一心达到一致。貌似无论怎么着,view 和对应的 controller 都密不可分的耦合在同步,由此可知,依然会把它们正是四个组件来相比。Apple 提供的那个组件一度以来在某种程度误导了大约初学者,初学者将全体的视图全体拖到 xib 中,连接大量的 IBoutLet 输出口属性,都以有些列难题。
  • Model : 承接NSObject, 担任保存数据.
  • View : 视图控件, 经常用xib来描述它里面的子控件,担任将数据显示在UI分界面上
  • Controller : 调整器,担当央求及处理网络数据, 管理客商交互

四个页面中涉及的逻辑首要有:创立UI控件、读取缓存数据、发送互联网伏乞、管理央求重临数据、更新UI彰显、管理客商触摸。假诺不选拔别的的设计方式,那么那么些页面的代码就可以相当短、臃肿杂乱,难以维护、修改。

1)MVVM 情势下的八天性状的分析:
  • 职务均摊 -- MVVM 的 View 要比 MVP 中的 View 承担的任务多。因为前面一个通过 ViewModel 的设置绑定来更新景况,而后人只监听 Presenter 的事件但并不会对友好有啥更新。

  • 可测量检验性 -- ViewModel 不精通关于 View 的别的业务,那允许大家得以随性所欲的测量检验 ViewModel。同期 View 也足以被测量检验,可是出于属于 UIKit 的框框,对她们的测试日常会被忽视。

  • 易用性 -- 在实际上支付中必需把 View 中的事件指向 Presenter 况且手动的来更新 View,借使采纳绑定的话,MVVM 代码量将会小的多。

2.在Controller里面,央浼数据,用第三方框架把数量转化成模型存进Model这几个类中, 然后给cell的item属性赋值,那样子就足以把item传进View里面------一言以蔽之,正是在Controller里面把数量传进View里面

敲定:主体采取MVC,局地看景况选拔MVVM设计方式,那样比较适用于当下的iOS开垦。

2)iOS MVVM示意图:

iOS MVVM 示意图.png

  • 在 MVVM 里,view 和 view controller 正式关系在共同,我们把它们就是三个零部件。视图 view 还是不能够向来引用模型 Model,当然 controller 也无法。相反,他们援引视图模型 View Model。

  • View Model 是一个停放客商输入验证逻辑,视图突显逻辑,发起互联网诉求和别的美妙绝伦的代码的极好的地点。有一件专门的学问不应归入View Model,那就是别的视图本人的援引。View Model 的定义同有时间适用于于 iOS 和 OS X(换句话说,不要在 View Model 中接纳 #import UIKit.h)。

  • 出于显得逻辑(presentation logic)放在了 View Model 中(比如 Model 的值映射到二个格式化的字符串),视图调节器本身就能够不再臃肿。当然你从头采取MVVM 的最佳点申时能够先将一小部分逻辑放入视图模型,然后当您逐级习贯于采用这些范式的时候再迁移越多的逻辑到视图模型中。

  • 运用 MVVM 会轻微的扩张代码量,但总体上减小了代码的复杂。

我们在央求互连网数据的时候,通平常服装务器给大家回去都是json也许xml数据,我们选拔第三方框架将它剖析之后会赢得三个字典数组.那时候假若我们面向字典来开荒:1.如此不太符合大家面向对象支付的宏大观念觉悟2.出于xcode的缘故,在敲字典的key时候系统是不会给我们提醒(也正是电动联想成效)的,那样便于产生大家有时不当心敲错了一个key导致加载不出数据,不过系统又不会报错,代码一多很或者将要花大多时间去找八哥,专门的学问点来说正是容错率低.

苹果官方是将MVC设计格局作为iOS 应用程式的正式格局

四、参考

http://www.cnblogs.com/QianChia/p/5771091.html
http://www.cnblogs.com/dubo-/p/5619077.html
http://www.cnblogs.com/end/archive/2011/06/02/2068512.html

他俩三小家伙的涉嫌如下:

能够下载上面包车型大巴demo看一下就通晓了,demo写得很轻巧!

4)MVP的优势
  • 模型与视图完全分开,大家可以修改视图而不影响模型
  • 能够越来越高速地应用模型,因为所以的互动都发出在一个地方——Presenter内部
  • 作者们能够将四个Presener用于五个视图,而不必要退换Presenter的逻辑。那么些特点特别的有用,因为视图的扭转总是比模型的转移频仍。
  • 假设我们把逻辑放在Presenter中,那么我们就能够脱离顾客接口来测量检验这几个逻辑(单元测量试验)

这标准,他们多少个各司其职, 符合我们高内聚,低耦合的观念.

如此那般的细分很好精晓,维护时,只要找到呼应的那一块实行退换就好了。

一、MVC

  • 从字面意思来精晓,MVC 即 Modal View Controller(模型 视图 调节器),是 Xerox PARC 在 20 世纪 80 时代为编制程序语言 Smalltalk-80 发明的一种软件设计方式,于今已普及应用于客商交互应用程序中。其意图在于将数据与视图分离开来。在 iOS 开采中 MVC 的编制被运用的不亦乐乎,丰硕知晓 iOS 的 MVC 形式,有利于大家先后的团队创建。

MVC 的几个了解的特征和反映:

  • View 上边展现怎么东西,取决于 Model。
  • 假设 Model 数据改了,View 的来得状态会随之变动。
  • Control 肩负伊始化 Model,并将 Model 传递给 View 去解析展现。

1)Modal模型对象:

  • 模型对象封装了应用程序的多少,并定义操控和管理该数据的逻辑和运算。比如,模型对象或许是意味着商品数量 list。客户在视图层中所进行的始建或涂改数据的操作,通过调控器对象传达出来,最后会创立或更新模型对象。模型对象改动时(例如通过网络连接接收到新数据),它打招呼调控器对象,调控器对象更新相应的视图对象。

2)View 视图对象:

  • 视图对象是应用程序中顾客可以看见的对象。视图对象明白怎么样将团结绘制出来,恐怕对顾客的操作作出响应。视图对象的首要指标就是显示来自应用程序模型对象的数额,并使该数据可被编辑。就算如此,在 MVC 应用程序中,视图对象平时与模型对象分别。
  • 在iOS应用程序开辟中,全数的控件、窗口等都三番七次自 UIView,对应 MVC 中的 V。UIView 及其子类首要承担 UI 的达成,而 UIView 所爆发的平地风波都足以应用委托的点子,交给 UIViewController 完结。

3)Controller 调节器对象:

  • 在应用程序的贰个或多少个视图对象和二个或七个模型对象之间,调整器对象肩负红娘。调整器对象由此是一路管道程序,通过它,视图对象明白模型对象的转移,反之亦然。调整器对象还是能为应用程序实行设置和协和职责,并保管其他对象的生命周期。

  • 调整器对象解释在视图对象中进行的顾客操作,并将新的或改变过的数量传达给模型对象。模型对象改换时,两个调整器对象会将新的模子数据传达给视图对象,以便视图对象能够呈现它。

  • 对于不一样的 UIView,有相应的 UIViewController,对应 MVC 中的 C。举例在 iOS 上常用的 UITableView,它所对应的 Controller 正是UITableViewController。

由此为了契合社会主义发展的脚步,我们须要将字典数组转换为模型数组,也等于将字典转为模型, 那将要扯到MVC那么些设计情势了.

查看了百度完善及网络海博物院客的一对表达, 为啥会叫ViewModel? 总括来说就是:MVVM由MVP和WPF结合作演出变过来的,MVVM形式是将业务分为3块M-V-新对象,由于那么些新目的是为View量身定制的,被称作ViewModel。MVVM的主旨是双向绑定。

#import "LJWAllTableViewCell.h"#import "tagItem.h"@interface LJWAllTableViewCell()@property (weak, nonatomic) IBOutlet UILabel *nameLabel;@property (weak, nonatomic) IBOutlet UILabel *numberLabel;@property (weak, nonatomic) IBOutlet UIImageView *imageV;@end-setItem:(tagItem *)item{ _item = item; //名字********************* _nameLabel.text = item.theme_name; //订阅数****************** NSString *numStr = [NSString stringWithFormat:@"%@人订阅",_item.theme_name]; CGFloat num = [_item.sub_number floatValue]; if (num > 10000) { num = num / 10000; numStr = [NSString stringWithFormat:@"%.1f人订阅",num]; } _numberLabel.text = numStr; //图片 ******************** [_imageV sd_setImageWithURL:[NSURL URLWithString:_item.image_list] placeholderImage:[UIImage imageNamed:@"defaultUserIcon"] completed:^(UIImage * _Nullable image, NSError * _Nullable error, SDImageCacheType cacheType, NSURL * _Nullable imageURL) { //生成圆形图片 //开启上下文 UIGraphicsBeginImageContextWithOptions(image.size, NO, 0); //描述裁剪路径 UIBezierPath *path = [UIBezierPath bezierPathWithOvalInRect:CGRectMake(0, 0, image.size.width, image.size.height)]; //设置裁剪区域 [path addClip]; //开始裁剪 [image drawAtPoint:CGPointZero]; //获取裁剪后的图片 image = UIGraphicsGetImageFromCurrentImageContext(); //关闭上下文 UIGraphicsEndImageContext(); _imageV.image = image; }];

先看这么划分后的分工:

时时app平台注册网站 566666.png

不管是MVCMVPMVVM都以对页面逻辑业务的一种OOP的划分!

上面用简短的table view实例来解说一下MVC的施用,如下图的功用

能够先经过博客通晓RAC:RactiveCocoa的行事规律归纳介绍

粗粗思路就是那般, 还应该有一点细节的事情逻辑之类的依据实际须求管理好就行.

View :UI分界面的创制及依靠传递的Model来更新视图的逻辑 。

Controller :担任控制器自个儿的生命周期,和睦各样部分的绑定关系以及须求的逻辑处理。

ViewModel :网络央浼、重回数据逻辑和缓存读写。

Model :用来将数据模型化,是数量查看更清晰,使用更方便人民群众。

MVC是四个单词的首字母缩写, 他们分别是 , 他们分别是, 分别是Model, View, Controller, 也正是模型, 视图, 调节器.

MVP设计情势是MVC的精耕细作,MVVM是MVC的创新!在IOS中,MVP设计格局并不流行,MVVM维护性强、耦合度低、能够减轻controller过于臃肿的难点;而MVC因为V和C总是成对出现,MVC实际上M-VC,耦合度照旧高了;但是在有个别简约逻辑的调整器里面MVVM写法还是麻烦了一些!

用MVC在随后得以实惠地对代码举行维护, 能够高达"哪儿出标题,就去找对应的类修改"的效果.

绑定的情趣就是讲七个对象构建关联,个中二个改观另贰个机关跟着变。倘使Model与View绑定就象征Model退换时View自动跟着变,没有必要手动赋值那一步---即响应式

另一方面绑定:诚如指模型数据变化触发对应的视图数据变化。

双向绑定:指模型数据,视图数据率性一方变化,都会接触另一方的四头变化。

下一篇将写MVVM的规划情势.

MVC是最广泛认识的设计情势,MVC方式将页面的逻辑分为3块:ModelViewController

//发送网络请求-loadData{ AFHTTPSessionManager *mgr = [AFHTTPSessionManager ljw_manager]; NSMutableDictionary *parameters = [NSMutableDictionary dictionary]; parameters[@"a"] = @"tag_recommend"; parameters[@"action"] = @"sub"; parameters[@"c"] = @"topic"; self.mgr = mgr; [mgr GET:@"http://api.budejie.com/api/api_open.php" parameters:parameters progress:nil success:^(NSURLSessionDataTask * _Nonnull task, NSDictionary * _Nullable responseObject) { //字典数组转模型数组 _tags = [tagItem mj_objectArrayWithKeyValuesArray:responseObject]; [self.tableView reloadData]; [SVProgressHUD dismiss]; } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) { NSLog(@"%@",error); [SVProgressHUD dismiss]; }];}

#pragma mark - Table view data source//设置cell的高度-tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{ return 60   10;}- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { return _tags.count;}-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{ LJWAllTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:ID]; tagItem *item = _tags[indexPath.row]; //把数据传给cell cell.item = item; return cell;}

二个app开采的严重性流程能够简轻易单总结为:搭建UI界面---> 乞请服务器数据 ---> 把数据映今后UI分界面上 --> 管理UI分界面包车型客车政工逻辑 ---> 测验及优化

#import <Foundation/Foundation.h>@interface tagItem : NSObject@property(nonatomic,strong)NSString *image_list;@property(nonatomic,strong)NSString *sub_number;@property(nonatomic,strong)NSString *theme_name;@end

本文由时时app平台注册网站发布于编程知识,转载请注明出处:iOS MVC、MVP、MVVM时时app平台注册网站

关键词: