网站开发属于技术合同,phpcms 手机网站模板,crm管理系统是什么意思,律师做网站MVC、MVP、MVVM
前言
这篇文章简单介绍MVC、MVP和MVVM三种架构#xff0c;并配上一个简单的Swift demo来区分MVC和MVVM两种架构。
MVC
传统MVC
下图是传统结构MVC#xff0c;可以看到这种结构是紧耦合的#xff0c;不推荐使用。 苹果的MVC
如下图#xff0c;这是苹果…MVC、MVP、MVVM
前言
这篇文章简单介绍MVC、MVP和MVVM三种架构并配上一个简单的Swift demo来区分MVC和MVVM两种架构。
MVC
传统MVC
下图是传统结构MVC可以看到这种结构是紧耦合的不推荐使用。 苹果的MVC
如下图这是苹果MVC架构的愿景Controller作为View和Model的中介这样它们就解耦了。 各层的职责如下所示
Model 数据层负责数据的处理和获取的数据接口层。View 展示层(GUI)对于 iOS 来说所有以 UI 开头的类基本都属于这层。Controller 控制器层它是 Model 和 View 之间的胶水或者说是中间人。一般来说当用户对 View 有操作时它负责去修改相应 Model当 Model 的值发生变化时它负责去更新对应 View。
如上图所示M和View应该是完全隔离的由C作为中间人来负责二者的交互同时三者是完全独立分开的这样可以保证M和V的可测试性和复用性。
MVC在iOS中的实现
由于Apple的规范一个界面的呈现都需要构建一个viewcontroller而每个viewcontroller都带有一个根view这就导致C和V紧密耦合在一起构成了iOS里面的C层这明显违背了MVC的初衷。实际结构如下图。 根据苹果对MVC架构规范的描述原文戳这里viewcontroller其实是view和controller的组合目的就是为了提高开发效率简化操作。但这样也会导致一个问题就是View层的代码全堆到了VC比如VC中构建ViewView的显示逻辑处理等等。
MVC各层功能
controller层VC
生成view然后组装view响应View的事件和作为view的代理调用model的数据获取接口拿到返回数据处理加工渲染到view显示处理view的生命周期处理界面之间的跳转
model层
业务逻辑封装提供数据接口给controller使用数据持久化存储和读取作为数据模型存储数据
view层
界面元素搭建动画效果数据展示接受用户操作并反馈视觉效果
关于Model层这里有一段文章引用说明了真正的Model层实际不应该只有几个结构和属性应该有的是数据的业务逻辑。 理解Model层 首先要正确的理解MVC中的M是什么他是数据模型吗答案是NO。他的正确定义是业务模型。也就是你所有业务数据和业务实现逻辑都应该定义在M层里面而且业务逻辑的实现和定义应该和具体的界面无关也就是和视图以及控制之间没有任何的关系它是可以独立存在的您甚至可以将业务模型单独编译出一个静态库来提供给第三方或者其他系统使用。 在上面经典MVC图中也很清晰的描述了这一点 控制负责调用模型而模型则将处理结果发送通知给控制控制再通知视图刷新。因此我们不能将M简单的理解为一个个干巴巴的只有属性而没有方法的数据模型。 其实这里面涉及到一个最基本的设计原则那就是面向对象的基本设计原则就是什么是类类应该是一个个具有不同操作和不同属性的对象的抽象类是属性和方法的集合。 我想现在任何一个系统里面都没有出现过一堆只有数据而没有方法的数据模型的集合被定义为一个单独而抽象的模型层来供大家使用吧。 我们不能把一个保存数据模型的文件夹来当做一个层这并不符合横向切分的规则。 Model层实现的正确姿势 定义的M层中的代码应该和V层和C层完全无关的也就是M层的对象是不需要依赖任何C层和V层的对象而独立存在的。整个框架的设计最优结构是V层不依赖C层而独立存在M层不依赖C层和V层独立存在C层负责关联二者V层只负责展示M层持有数据和业务的具体实现而C层则处理事件响应以及业务的调用以及通知界面更新。三者之间一定要明确的定义为单向依赖而不应该出现双向依赖M层要完成对业务逻辑实现的封装一般业务逻辑最多的是涉及到客户端和服务器之间的业务交互。M层里面要完成对使用的网络协议(HTTP, TCP其他)、和服务器之间交互的数据格式XML, JSON,其他)、本地缓存和数据库存储COREDATA, SQLITE,其他)等所有业务细节的封装而且这些东西都不能暴露给C层。所有供C层调用的都是M层里面一个个业务类所提供的成员方法来实现。也就是说C层是不需要知道也不应该知道和客户端和服务器通信所使用的任何协议以及数据报文格式以及存储方面的内容。这样的好处是客户端和服务器之间的通信协议数据格式以及本地存储的变更都不会影响任何的应用整体框架因为提供给C层的接口不变只需要升级和更新M层的代码就可以了。比如说我们想将网络请求库从ASI换成AFN就只要在M层变化就可以了整个C层和V层的代码不变。 MVP
结构如下图。 MVC中没有对业务逻辑和业务展示进行区分MVP就是针对这一点进行的优化它将业务逻辑和业务展示做了一层隔离。M和V功能不变, 原来的C现在只负责布局, 而所有的业务逻辑全都转移到了P层。P层处理完了业务逻辑如果要更改view的显示那么可以通过回调来实现这样可以减轻耦合MVP从视图层中分离了行为事件响应和状态属性用于数据展示它创建了一个视图的抽象也就是presenter层而视图就是P层的『渲染』结果。P层中包含所有的视图渲染需要的动态信息包括视图的内容text、color、组件是否启用enable除此之外还会将一些方法暴露给视图用于某些事件的响应。
MVP通信过程 当视图接收到来自用户的事件时会将事件转交给 Presenter 进行处理被动的视图实现presenter的代理当需要更新视图时 Presenter回调代理来更新视图的内容这样让presenter专注于业务逻辑view专注于显示逻辑Presenter 负责对模型进行操作和更新在需要时取出其中存储的信息当模型层改变时可以将改变的信息发送给观察者 Presenter
MVVM
MVVM由三个部分组成也就是 Model、View 和 ViewModel其中视图模型ViewModel其实就是 MVP 模式中的P在 MVVM 中叫做VM架构图如下。 MVVM相对于MVP做的改进就是对VM/P和view做了双向的数据和命令绑定利用Binder机制使得Model和View可以状态同步。
具体实例看MVC与MVP/MVVM的实现对比 可以看到项目中MVVM比MVC多了一个ViewModel层这是两者的不同我们先来看看相同的Model和ViewController两者除了命名不同其他的都相同所以以下只展示一种。
Model ViewController fetchData部分写的内容是模拟网络请求数据代码如下图。
fetchData 接下来让我们看到MVC中的View层
MVCView 可以看到在这里对业务的显示和业务的逻辑处理都放在了View层。
我们反观MVVM架构中加入了一个ViewModel它对业务逻辑部分抽象出了一个类代码如下。 最后我们在View中只用处理业务展示部分即可代码如下。 以上就是MVC、MVP、MVVM的简要介绍。
