iOS开发之常用技术点

在 iOS 上实现基于协议的 MVP

2019-01-17  本文已影响68人  大青虫Insect

概述

如果你做过 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

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

  1. 用户输入账号密码，点击登录时判断用户名和密码有没有输入，没有内容时提示用户输入。

  2. 本地模拟网络请求，随机返回用户登录成功或是失败。登录成功时，返回首页并显示用户名。登录失败时，显示 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，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的接口，去观察功能上的操作，然后考虑：

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 层。

最后

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

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

上一篇下一篇

猜你喜欢

热点阅读