概述

如果你做过 Android 开发，那你一定知道，MVP 是 Google 官方推荐的 Android 开发架构。和 iOS 一样，Android 也存在着如果代码不够规范导致 C 层(Activity)过于臃肿的问题。

对于 MVP ，Android 无论是 Java 或是 Kotlin 都是基于 Interface 来实现的。如果你学习过 Java 或者 Kotlin 就会发现，Interface 和 iOS 里的 Protocol 还是十分相似的，只是 Obj-C 的 Protocol 相比其他几个在功能上稍微弱势一点。

本篇将教大家如何在 iOS 中使用 Protocol 实现类似 Android 的 MVP 架构。本篇灵感来自以下 Blog
浅谈 MVP in Android
Android MVP 十分钟入门！

Login Demo

这里我们以登录为例，说一下我们的需求。

用户输入账号密码，点击登录时判断用户名和密码有没有输入，没有内容时提示用户输入。
本地模拟网络请求，随机返回用户登录成功或是失败。登录成功时，返回首页并显示用户名。登录失败时，显示 Error 的信息。

运行效果

试想一下在传统的 MVC 中我们会如何处理，C 持有两个 UITextField。

 @IBOutlet private weak var accountTF: UITextField!
 @IBOutlet private weak var pwdTF: UITextField!

并添加按钮点击事件

// MARK: - 点击登录
 @IBAction func loginBtnDidClick() {
        
 }

在点击事件中，判断两个 UITextField 的输入内容是否合法。不合法时显示 Toast，合法时发起网络请求，在成功和失败的回调中分别对 UI 做出处理。

这种方式有什么不好呢？为什么我们的 C 层写着写着就变得异常臃肿？其实很大原因是因为 C 层的职责不够明确， C 层既负责了逻辑的处理，也负责了 UI 的变化。

MVP

接下来我们用 MVP 的思想优化这个 Demo。MVP 所做的事情很简单，就是将业务逻辑和视图逻辑抽象到 Protocol 中。

Model: 在 iOS 的 MVC 中 Model 通常都是指数据模型，目的是方便我们进行数据的操作。但在 MVP 中 Model 除了提供数据模型外，还负责处理具体的业务逻辑，比如我们这里的登录请求。需要注意的是，在 Model 里不应当持有 View。
View: 只负责响应 UI 变化，不负责处理业务逻辑。
Presenter: 负责完成 View 于 Model 间的交互。

完工以后，我们的目录是这样的，接下来开始一步步编写思路。

定义 Model，View，Presenter 的 Protocol

Model - Protocol

首先登录返回的用户信息类肯定是必不可少的

struct User: Codable {
    
    /// 姓名
    let name: String
    /// 年龄
    let age: Int
}

其次还需要一个业务方法 Login

protocol LoginModelProtocol: class {
    
    /// 登录逻辑处理
    func login(account: String, pwd: String)
}

View - Protocol

protocol LoginViewProtocol: class {
    
    /// 账号
    func account() -> String
    /// 密码
    func password() -> String
    /// 输入不合法
    func showToast(_ text: String)
    /// 请求正在进行中
    func showLoading()
    /// 网络请求返回, 登录成功
    func loginSuccess(_ response: User)
    /// 网络请求返回, 登录失败
    func loginFailure(_ error: String)
}

对于View的接口，去观察功能上的操作，然后考虑：

该操作需要什么？（account, password）
该操作的结果，对应的反馈？(showToast, loginSuccess, loginFailure)
该操作过程中对应的友好的交互？(showLoading)

Presenter - Protocol

Presenter Protocol 作为连接 Model 和 View 的中间桥梁，需要将二者连接起来，因此他需要完成以下工作：

响应登录按钮点击事件
响应不合法事件，显示提示
登录请求中
网络请求成功回调
网络请求失败回调

因此，Presenter 就可以这么定义：

protocol LoginPresenterProtocol: class {
    
    /// 登录
    func login()
    /// 显示提示
    func showToast(_ text: String)
    /// 登录请求中
    func loading()
    /// 网络请求返回, 登录成功
    func loginSuccess(_ response: User)
    /// 网络请求返回, 登录失败
    func loginFailure(_ error: String)
}

Model，View，Presenter 的具体实现

Model

还记得我们刚刚所说的，在 MVP 中，Model 的工作就是完成具体的业务和逻辑操作。比如说网络请求，持久化数据增删改查等。同时Model中又不会包含任何View。

class LoginModel {
    
    weak var present: LoginPresenter?
    
    init(present: LoginPresenter?) {
        self.present = present
    }
}

// MARK: - LoginModelProtocol
extension LoginModel: LoginModelProtocol {
    
    func login(account: String?, pwd: String?) {
        
        guard let account = account, let pwd = pwd else {
            
            present?.showToast("账号密码不合法") 
            return
        }
        if account.count == 0 || pwd.count == 0 {
            
            present?.showToast("账号密码不合法")
            return
        }
        
        present?.loading()
        Net.login(account: account, pwd: pwd, success: { [weak self] in
            self?.present?.loginSuccess($0)
        }) { [weak self] in
            self?.present?.loginFailure($0)
        }
    }
}

Presenter

class LoginPresenter {
    
    var model: LoginModelProtocol?
    weak var view: LoginViewProtocol?
    
    init(view: LoginViewProtocol?) {
        
        self.view = view
        model = LoginModel(present: self)
    }
}

// MARK: - LoginPresenterProtocol
extension LoginPresenter: LoginPresenterProtocol {
    
    func login() {
        model?.login(account: view?.account(), pwd: view?.password())
    }
    
    func loading() {
        view?.showLoading()
    }
    
    func loginSuccess(_ response: User) {
        view?.loginSuccess(response)
    }
    
    func loginFailure(_ error: String) {
        view?.loginFailure(error)
    }
    
    func showToast(_ text: String) {
        view?.showToast(text)
    }
}

可以看到，我们在 LoginPresenter 的构造方法中，同时实例化了Model 和 View，这样 Presenter 中就同时包含了两者。在 Presenter 的具体实现中，业务相关的操作由 Model 去完成（例如 Login），视图相关的操作由 View 去完成（例如获取用户输入内容等）。Presenter 只作为一个桥梁，巧妙的将 View 和 Model 的具体实现连接了起来。

View

最后再看一下 View 的具体实现，也就是 Controller 的实现：

class LoginViewController: UIViewController {

    private var present: LoginPresenter?
    
    // MARK: - IBOutlet
    @IBOutlet private weak var accountTF: UITextField!
    @IBOutlet private weak var pwdTF: UITextField!
    
    // MARK: - LifeCycle
    override func viewDidLoad() {
        super.viewDidLoad()
        present = LoginPresenter(view: self)
    }
    
    deinit {
        
        present?.detachView()
        print("销毁----------")
    }
    
    // MARK: - 点击登录
    @IBAction func loginBtnDidClick() {
        present?.login()
    }
}

// MARK: - LoginViewProtocol
extension LoginViewController: LoginViewProtocol {
    
    func account() -> String {
        return accountTF.text ?? ""
    }
    
    func password() -> String {
        return pwdTF.text ?? ""
    }
    
    func showLoading() {
        Toast.loading()
    }
    
    func showToast(_ text: String) {
        Toast.show(info: text)
    }
    
    func loginSuccess(_ response: User) {
        
        Toast.show(info: ""
        \(response.name) \n
        登录成功
        "")
        dismiss(animated: true, completion: nil)
    }
    
    func loginFailure(_ error: String) {
        Toast.show(info: error)
    }
}

至此，我们就通过 MVP 实现了之前所设想的业务逻辑和 UI 变换分离的 C 层。

Button 的点击负责发起登录任务，但又不负责具体实现，而是由Presenter 转接给 Model 去实现
Controller 什么时候显示 Toast，什么时候跳转界面直接由 Presenter 告诉他，他只做一个 View 该做的事情
Controller 里没有任何逻辑处理，所有的逻辑处理都在 Model 中完成了

最后

看到这里其实你会发现，虽然我们的业务逻辑变得清晰了。但不可避免的我们增加了更多的类和代码，这点其实非常类似于 MVVM，相比原来简单的实现，我们需要写更多的胶水代码。

但是随着项目规模的增大，代码逻辑清晰所带来的影响是非常深远的。维护低耦合，高内聚，优雅，健壮的代码不管对自己或是别人来说都是一种享受。

在 iOS 上实现基于协议的 MVP

概述