An understanding of MVVM under iOS development

Recently seen on the Sina Weibo and iOS development forum talk about the MVVM design pattern, so-called MVVM is the abbreviation of Model-view-viewmodel, about the concept of MVVM, here I do not want to introduce too much, there are many introduced very detailed blog, here we go straight to the topic, Talk about how MVVM is used in the project.

First of all, we can be divided into the following modules when building a project, Model,view,viewmodel,controller.

Model: Data models for processing data

View: Class for interface design

ViewModel: Used to write interface and logic

Controller: Class of controllers to handle logic between controllers

Some people here are sure to ask, is MVVM not Model-view-viewmodel, why there is a controller, where the controller is used to provide access to the page jump and load, as well as the controller logic to take advantage of the proxy and code block way for ViewModel to implement. Light say no practice false bashi, first look at the folder bar.

As I said before, the module is divided into 4 parts, so that we can make our controller is no longer so (fat), compared with the traditional MVC, the file is more, but in this way, the controller inside the code is reduced a lot, only need to invoke the function of the corresponding functions can be. And then we'll see what ViewModel is writing.

#import<Foundation/Foundation.h>#import<UIKit/UIKit.h>#import "WeatherView.h"#import "weatherModel.h"@interfaceWeatherviewmodel:nsobject@property (nonatomic, strong) Weatherview*view;/**< is used to match the view inside the controller.*/@property (nonatomic, strong) Weathermodel*model; @property (nonatomic, strong) UITableView*Mytableview;-(Instancetype) initWithFrame: (CGRect) frame;
-(void) didselect;@end

#import "WeatherViewModel.h"#import "WeatherTableViewCell.h"#import "weathermodel+request.h"StaticNSString *ConstKapiurl =@"www.baidu.com";@implementationWeatherviewmodel-(Instancetype) initWithFrame: (CGRect) frame { self=[Super Init]; if(self) {[self initwithmodel]; _view=[[Weatherview alloc]initwithframe:frame];    [_view AddSubview:self.myTableView]; }    returnSelf ;}- (void) Initwithmodel {[Weathermodel requestwithurl:kapiurl andparmars:@{} withsuccessblock:^(IDresponseobject) {Self.model= responseobject[@"Data"]; } Withfailblock:^(IDerror) {        }];}-(UITableView *) Mytableview {if(!_mytableview) {_mytableview=[[UITableView alloc]initwithframe:_view.frame Style:uitableviewstyleplain]; _mytableview.tablefooterview=[[UIView alloc]init]; _mytableview.backgroundcolor=[Uicolor Yellowcolor]; }    return_mytableview; }

-(void) didselect {   

NSLog(@ " clicked Cell");

}

Here I directly put the UI is also written in, here you may have to ask, not to say is ViewModel, and this class is inherited NSObject, why to write the UI here. Yes, it seems to me to be just a tool class, but my goal is to make the controller a little simpler, so that when we look at a controller, we just need to know what it does and what it can do. All the rest is given to ViewModel to deal with it. We can put the network request and some logic processing all come in, greatly reduce the coupling degree of the code.

And then we'll look at what the controller says,

#import "WeatherViewController.h"#import "WeatherViewModel.h"#import "WeatherTableViewCell.h"@interfaceWeatherviewcontroller () <UITableViewDataSource,UITableViewDelegate>{Weatherviewmodel*viewmodel;/**< The ViewModel of the current controller*/}@end@implementationWeatherviewcontroller- (void) viewdidload {[Super viewdidload];    [Self setUp]; //Do any additional setup after loading the view.}- (void) setUp {self.title=@"Weather Test"; ViewModel=[[Weatherviewmodel alloc] initWithFrame:self.view.bounds]; Viewmodel.mytableview.Delegate=Self ; ViewModel.myTableView.dataSource=Self ; [Self.view AddSubview:viewModel.view];}-(Nsinteger) Numberofsectionsintableview: (UITableView *) TableView {return 1;}-(Nsinteger) TableView: (UITableView *) TableView numberofrowsinsection: (nsinteger) Section {return  -;}-(UITableViewCell *) TableView: (UITableView *) TableView Cellforrowatindexpath: (Nsindexpath *) Indexpath {StaticNSString *reuseidentifier =@"Reuseidentifier"; Weathertableviewcell*cell =[TableView Dequeuereusablecellwithidentifier:reuseidentifier]; if(!cell) {Cell=[[Weathertableviewcell Alloc]initwithstyle:uitableviewcellstyledefault reuseidentifier:reuseidentifier]; Cell.textLabel.text=@"It is a test"; }    returncell;}- (void) TableView: (UITableView *) TableView Didselectrowatindexpath: (Nsindexpath *) Indexpath {[ViewModel didselect];}

The controller does not need to write the UI, directly to the viewmodel inside the definition of the view on the current controller on the view on it. To implement some of the necessary agents, here are sure to think, why the UI is written in the ViewModel, but also the proxy method written in the controller, here I tried to write in the ViewModel, but there will be a cell reuse problem. If you have a good solution, please give me a message, thank you very much.

about how the logic of the controller to ViewModel, can have agents, blocks, or notice, of course, the most perfect when the Reactivecocoa, about the REACTIVECOCOA framework of the introduction there are many, here is a better article REACTIVECOCOA2 source Analysis.

These are some of the personal understanding of MVVM, there must be some deficiencies in the process of understanding, I hope in the later use process can have a better summary.

An understanding of MVVM under iOS development