iOS MVP设计模式实现

本文深入讲解MVP(Model-View-Presenter)模式,探讨其在软件架构中的作用及实现细节,包括Model、View和Presenter之间的交互,以及如何通过Presenter解耦View与Model,提升代码的可维护性和可扩展性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

MVP:

MVP模式是MVC模式的一个演化版本(好像所有的模式都是出自于MVC~~),MVP全称Model-View-Presenter。顾名思义,

Model:与MVC中的model没有太大的区别。主要提供数据的存储功能,一般都是用来封装网络获取的json数据的集合。Presenter通过调用Model进行对象交互。

View:这里的View与MVC中的V又有一些小差别,这个View可以是viewcontroller、view等控件。Presenter通过向View传model数据进行交互。

Presenter:作为model和view的中间人,从model层获取数据之后传给view,使得View和model没有耦合

MVP的概念图:

文件结构:

代码给出了一个控制器作为例子,大家可以看到,home里面包含了四个文件夹,model、controller、presenter、view。home当中的HomePresenter是继承presenter的,HomePresenter根据业务的不同来实现自己的presenter。

网络:

网络的底层还是用AFNetWorking来实现,HttpClient具体的封装大概为:

这里用delegate而不用block做回调是因为后面的HomePresenter需要对返回的数据进行处理,为了然后结构更加清晰,遵守一个函数一个功能的原则。后面还会再说一下。HttpClient提供了赋值responseHandle的init函数,外部可以通过init函数来绑定responseHandle协议。

再来看一下上面那个responseHandle这个proctocol的结构:

目前只写了success和fail两个回调,这里为了方便演示,只写了一个参数,这个一块大伙可以根据自己的业务需求来写。

结合HttpClient来看一下,我们分别在AFNetWorking请求成功、失败的回调当中处理delegate。简单说,HttpResponseHandle就是嫁接presenter和HttpClient的协议:

接下来看一下父类Presenter的设计。先看接口:

这里采用了泛型,简单说泛型就是有点类似objective-c中的id类型。父类Presenter主要是提供绑定View和解绑View的功能。

基于网络请求设计的HttpPresenter,HttpPresenter继承与Presenter,遵守HttpResponseHandle协议,并且拥有自己的泛型,HttpClient成员变量。供外部调用HttpClient,降低耦合性。

应用:

大致就可以分为这几层了,看一下怎么应用到实例中。

上文的文件目录中可以看出我们每个功能模块都有presenter这个文件夹,对每个模块的presenter都是为这个模块服务,我们可以把请求、储存数据的活动放在这里。并且在这层presenter中处理model数据。为了使controller得到的数据能直接使用,可以多写一个protocol,来承上启下,HomeViewProtocol就为了这个产生。

@protocol HomeViewProtocol
- (void)onGetMovieListSuccess:(HomeModel*)homeModel;
- (void)onGetMovieListFail:(NSInteger) errorCode des:(NSString*)des;
@end

先看了protocol,HomePresenter看起来就清晰多了

在看一下controller的调用,初始化HomePresenter,然后绑定一下自己的视图:

遵循HomeViewProtocol:

 

 

 

 

 

 

 

1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义   就一个类而言,应该仅有一个引起它变化的原因。 定义解读   这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出   假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案   遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。   说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值