MVC
每创建一个界面都需要创建一个controller,而每一个controller都会带view,这就导致了v和c的耦合.这种开发可以提升效率,但当一个界面比较复杂时候,contriller就会变得非常臃肿和难以维护,由于分散性,只能对Model进行测试.上面说了一堆MVC的缺点,那它有什么优点呢.
与其他集中开发模式相比,MVC是代码量最小的.熟悉的人很多,开发维护起来也较为容易.
MVP设计模式
我们首先要修一个protocol文件
//DemoProtocal
import <Foundation/Foundation.h>
@protocol DemoProtocal <NSObject>
@optional
//用户点击按钮 触发事件： UI改变传值到model数据改变 UI --- > Model 点击cell 按钮
-(void)didClickCellAddBtnWithIndexPathRow:(NSInteger)index;
//model数据改变传值到UI界面刷新 Model --- > UI
-(void)reloadUI;
@end
然后我们去present层去实现业务逻辑
//Presenter.h
#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
#import "DemoProtocal.h"
NS_ASSUME_NONNULL_BEGIN
@interface Presenter : NSObject
@property (nonatomic, strong,readonly) NSMutableArray *dataArray;
@property (nonatomic, weak) id<DemoProtocal>delegate;//协议，去更新主视图UI
// 更新 TableView UI 根据需求
- (void)requestDataAndUpdateUI;
//更新 cell UI
- (void)updateCell:(UITableViewCell*)cell withIndex:(NSInteger)index;
@end
我们在vc里面先实现tableiview,调用cell更新ui
//Controller 层
- (void)iniData{
self.presenter = [[Presenter alloc] init];
self.presenter.delegate = self;
[self.presenter requestDataAndUpdateUI];
}
...
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section{
return self.presenter.dataArray.count;
}
- (UITableViewCell*)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
MVPTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Cell_identifer"];
if(cell == nil){
cell = [[MVPTableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Cell_identifer"];
}
//更新cell UI 数据
[self.presenter updateCell:cell withIndex:indexPath.row];
cell.selectionStyle = UITableViewCellSelectionStyleNone;
return cell;
}
#pragma mark - DemoProtocal
//Presenter 的代理回调 数据更新了通知View去更新视图
- (void)reloadUI{
[self.mainTabelView reloadData];
}
总结,mvp的流程是把controller中的东西分出去了,但是呢.分出去之后 在controller中还需要用到presnent处理的数据,这个时候就必须把数据传递回来了.所以,上面的落成就是 当我们调用- (void)updateCell:(UITableViewCell*)cell withIndex:(NSInteger)index 更新 cell UI,这个时候presnet需要去处理数据,处理完数据以后,这时候我们要用之前写的Protocal文件中的协议-(void)reloadUI;来实现传值 通知已经处理完了.这样就形成了一个业务逻辑的分离.
上面说了mvp模式的一个简单过程,那么这种设计模式的优缺点有哪些呢.我们是不是要使用呢?
优点:
- 1 任务均摊:把controller控制器中的代码逻辑给划分开了,所以控制器中的代码不会变得臃肿
- 2.可测试性:既然view和逻辑都分开了,那就可以单独测试UI
- 3易用性:相较于MVC修改代码逻辑时候,可能牵连相关的东西.MVP区分开逻辑和UI之后,我们只在present中修改逻辑 对其他对方的代码是不需要改动的. 而且读起来也会更加清晰
- 4 可以更加高效的使用模型.
- 5.在需要复用界面中的逻辑时,我们不需要在重写,可以直接复用present中的逻辑.
- 6 单元测试.
缺点:
相较于mvc,他的代码量确实多了.需要创建protocol,而且随着交互越来越复杂,present也会变得特别臃肿,protocol的协议也会越来越多. 所以mvvm+rac就孕育而出了.
MVVM设计模式
MVVM是在mvp基础上改良而来的.为了更好的解耦 也不用大量的创建协议,这个时候我们可以使用RAC.它通过观察摸一个属性的变化来触发.
例如
//绑定输入框
RAC(self.viewModel,account) = [RACSignal merge:@[self.accountTextFiled.rac_textSignal,RACObserve(self.accountTextFiled, text)]];
RAC(self.viewModel,password) = [RACSignal merge:@[self.passwordTextField.rac_textSignal,RACObserve(self.passwordTextField, text)]];
//显示输入长度
[self.accountTextFiled.rac_textSignal subscribeNext:^(NSString * _Nullable x) {
@strongify(self);
if ([x length] > 11) {
self.accountTextFiled.text = [x substringToIndex:11];
}
}];
[self.passwordTextField.rac_textSignal subscribeNext:^(NSString * _Nullable x) {
@strongify(self);
if ([x length] > 6) {
self.passwordTextField.text = [x substringToIndex:6];
}
}];
点击登录 出判断验证码是否正确 然后请求数据,把请求的结果返回给controller,控制器再去做操作.
控制器绑定viewmodel
//监听button是否可用
RAC(self.loginBtn, enabled) = self.viewModel.loginBtnEnableSignal;
@weakify(self);
[RACObserve(self.loginBtn, enabled) subscribeNext:^(id _Nullable x) {
@strongify(self);
[self.loginBtn setBackgroundColor:[x boolValue]?kThemeColor:[UIColor colorWithHex:0xD0D0D0]];
}];
再来看viewmodel的操作
- (RACSignal *)loginBtnEnableSignal{
if (!_loginBtnEnableSignal) {
_loginBtnEnableSignal = [RACSignal combineLatest:@[RACObserve(self, account),RACObserve(self, password)] reduce:^id _Nonnull{
return @(self.account.length && self.password.length);
}];
}
return _loginBtnEnableSignal;
}
在viewmodel里面判断了账号密码的长度,然后再把结果给返回去.vc得到结果再去设置button是否可用.
如果账号密码符合规则 才能去模拟登录.
相较于MVP,最直观的是代码量少了.而且MVVM通过绑定viewmodel来更新状态.而MVP只能监听presenter的时事件,但它不会自己更新,
