原文链接 : 链接
一个整体的分层? 逻辑清晰? 还是清晰的分工? 对于架构模式来说并没有一个非常明确的定义, 比较抽象, 在于设计在于架构, 不管是小到类与类之间的交互, 还是不同的小模块, 小版块之间, 甚至于在不同的业务之间, 我们都可以去从架构的方面去理解, 去分析
那么我们平时开发用到的代理, block当然也是起到解耦合, 使代码的耦合度降低, 通知可以解决两者之间的相互引用并且实现解耦合
那么在iOS中常见的架构来说, 常见有哪些呢? MVC架构, MVP架构, MVVM架构
当然这些架构都有一个共同特点: 解耦合
本身来说View和Model, 但是在实际开发使用的时候, 还是有联系的, 这个平时开发的比较多, 下图是我简单画的一个关系图, 说明了三者之间的关系
下图画的一个简单的关系图, 那么我们根据这个简单的关系图用一个简单的demo来演示MVP是怎么进行两者中的关系处理的
面向接口编程
假如说我们需要处理点击事件, 那么可以在View中使用代理, 或者block, 之前使用MVC使用C来遵守协议, 那么MVP的话是怎样处理, 在P中来实现的, 逻辑处理是在P中来处理的, 此处MVP中的遵守协议一般情况下写在P中
下图是我简单画的一个关系图, 说明了三者之间的关系
这是vm层。
这是view层相当于mvc的c
这是controller层
响应式编程
也是由MVC来演变过来的, 和MVC相比的话, 我们的V取代了C中的业务逻辑处理, ViewModel并不是单纯的业务逻辑类, 和我们的View和Model是相互关联的, 并且进行了双向的绑定
假如说我们要添加点击事件,我们可以在ViewModel中来处理点击方法逻辑, 然后在我们View中导入ViewModel, 在View中点击调用点击方法的具体逻辑就可以了
