美文网首页UIKit移动开发技术前沿iOS入的那些坑
竭尽全力的去解耦的一次实践,封装一个TableView和一些功能

竭尽全力的去解耦的一次实践,封装一个TableView和一些功能

作者: 星光社的戴铭 | 来源:发表于2016-03-23 17:13 被阅读1274次

    可以先看看这个Demohttps://github.com/ming1016/DecoupleDemo。从这个Demo里可以看到Controller和View还有Store的头文件里没有任何Delegate,Block回调,只有初始化和更新ViewModel的方法。所有这些控件,请求,ViewController和视图之间的联系都是通过ViewModel来进行的,而viewModel也不进行任何逻辑处理,只是简单的起到描述和默认值设置的作用。ViewController也被减轻的小得不能再小了,只需要初始化视图和Store即可。这也是我的一次尝试,看看如何利用KVO能够做到最大限度的解耦,和最大限度的减少代码和接口。

    可以先看看以前代码最臃肿的地方在使用了新的思路后会变成怎么样,首先是ViewController

    - (void)viewDidLoad {
        [super viewDidLoad];
        [self addKVO];
        [self buildConstraints];
        self.tbStore = [[TestTableStore alloc] initWithViewModel:self.tbView.viewModel];
    }
    

    可以看到里面仅仅做了添加KVO,布局控件和初始化Store的工作。

    封装的TableView作为一个通用控件是不会去设置管理不同的Cell的,可以看看不用Delegate和Block是如何处理的。

    - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
        self.viewModel.tableViewIdentifier = smTableViewIdentifier;
        self.viewModel.tableView = tableView;
        self.viewModel.cellIndexPath = indexPath;
        return self.viewModel.cell;
    }
    

    我觉得这样应该很简化了。当触发到UITableView这个配置Cell的回调时,通过对ViewModel的键值的监听就能够在任何地方对Cell进行配置了,而不用通过繁琐的Delegate和Block来层层回调了。

    除了这里外,其它地方也用同样的方法进行了处理,比如说对新出现消息提示点击使其消失只需要设置ViewModel里的isHideHintView的值的处理,还有对请求不同状态显示不同引导页,只要是以前需要通过接口和回调的全部干掉,用ViewModel去控制,下面可以看看我写的ViewModel中,我将KVO分成了View Side和Data Side,前者主要是响应视图方面的逻辑变化,后者Data Side是响应不同的动作来产生对数据不同的处理,其它就都是些关于样式和数据配置相关的了。

    //---------------------------
    //           KVO View Side
    //---------------------------
    @property (nonatomic, assign) BOOL isHideGuideView;             //是否显示guide view
    @property (nonatomic, assign) BOOL isHideHintView;              //是否显示hint view
    //下拉刷新上拉加载更多
    @property (nonatomic, assign) SMTableRequestStatus requestStatus; //刷新状态
    //TableView Delegate
    //通用
    @property (nonatomic, strong) UITableView *tableView;
    @property (nonatomic, strong) NSString *tableViewIdentifier;
    //Cell
    @property (nonatomic, strong) NSIndexPath *cellIndexPath;
    @property (nonatomic, strong) UITableViewCell *cell;
    //CellHeight
    @property (nonatomic, strong) NSIndexPath *cellHeightIndexPath;
    @property (nonatomic, assign) CGFloat cellHeight;
    
    
    //---------------------------
    //          KVO Data Side
    //---------------------------
    @property (nonatomic, assign) SMTableRefreshingStatus dataSourceRefreshingStatus; //请求状态
    

    纵观整个项目,头文件都很干净,唯一有方法需要参数的也就是ViewModel。这种完全面向对象思路的编程方式在需求经常变更的情况下优势就会慢慢显露出来,对吧。

    相关文章

      网友评论

      • StrongX:说实话我并不觉得这样做有什么优势,你将你的tableView放到了一个view上,然后将view当作了Controller在用,所有的视图逻辑都在里面,反而使你的viewmodel看上去空空荡荡的。
      • 149a7611396f:一开始以为你说的是MVVM模式,看上面评论才知道并不遵守。这样写会不会误导新人呢
      • Maru:你好,常规的MVVM的思想我记得应该是,View持有ViewModel,他们之间的持有关系是单向的,他们之间的交互只是数据和方法的动态绑定,你这样的做法会不会耦合太强了呢。另外,在cellForRow方法中不停的赋值identifier和tableView这种绝大多数情况下不变的变量是不是也不够优雅呢?
        星光社的戴铭:@Maru 嗯,idenfier可以不用设置,在配置的地方去设置也行。耦合问题可以看看demo,这里的viewmodel是连接各个view,vc和数据的唯一纽带这样能够避免容易产生一堆不一致命名和混乱的层层的回调,这个方法也主要是解决这个问题。关于mvvm这种设计模式的遵守并不是这个demo的目的

      本文标题:竭尽全力的去解耦的一次实践,封装一个TableView和一些功能

      本文链接:https://www.haomeiwen.com/subject/kyallttx.html