换个角度来看MVC与MVP

2017-07-14

之前了解架构的时候，虽然能够看得懂MVC和MVP这些概念，但是却没有实感，总感觉很多地方其实并没有那么的明确。最近想起之前的讨论TTD的文章，忽然想到，为什么不从另一个角度来看待这两种模式呢，所以忽然醒悟，现在来讲讲这两种模式解决的问题。

无法解决的单元测试

最近在开发过程中，虽然大部分场景都比较简单，逻辑也非常清晰，但是也有部分场景的逻辑比较多，一些隐藏逻辑还难以通过造数据来进行测试，自然QA也基本覆盖不到这种测试场景，那么自然想到了单元测试，但是以目前我们项目的架构来说，单元测试基本不可能，业务逻辑、事件界面等揉合在一起，无从下手。

我们目前的架构来看，并不差，无论从实用性，易用性和复用性上来说。但是网上众多大神都极力推崇MVP和MVVM，我一直都没有太明白别人所说的优点真的如此神奇吗？直到最近想要对部分业务复杂的页面做单元测试，然后从TDD的角度再去看这些问题，才豁然开朗，下面就来简单介绍下。

架构之间的模糊性

我们来探讨一下，现在官方推荐的MVC架构在实战中的情况，真的能够分的如此清楚吗？

也有很多人把这种架构表示为这样：

1
2
3

---------------------          ---------
| view | controller |   ---->  | model |
---------------------          ---------

在现实中，view和controller往往是紧密而不可分的，事实上view也很难在不同的应用间（iPhone，iPad）复用。

很多时候为了模块的内聚性，需要映射view <- model，这就是有人提出的增加一个helper类，来负责这样的映射，但我不是非常认同，我更倾向于创建一个中间viewModel来做，事实上很多时候我们把model就直接作为viewModel。

// Helper 方式
Helper.apply(view:view, withModel:model)

// ViewModel 方式
class ViewModel {
  init(model: Any)
}
class View: UIView {
  var viewModel: ViewModel { set }
}

那么按照这么做，MVC的界限就真的清楚了吗？其实并没有，所以让我们忘了MVC的分层吧，这仅仅是一种思路，抽象后的概念，真正在实践中去探索才是最好的。

之前看过百度的一位大神，他曾经嘲笑那些把请求放到view层的设计，但后来想不到自己也这么做了。那么这里我举个例子，我们就拿最常用的star功能来说吧。功能很小很简单，一个按钮一个请求就可以搞定，那么如果我们要严格按照MVC的方式来写，那么就至少需要在每一个V和C中都写逻辑，而这部分逻辑虽然都是一样的，但却很难以复用，那么就很容易出现’copy-paste’的情况，那么为了增加这种功能模块的内聚性该如何做呢？最简单的做法那就是直接在view里写逻辑！！！如下：

class StarButton: UIButton {
    var id: String
    init(id: String) {
        self.id = id
        self.addTarget(self, action: #selector(onStar(sender:)), for: .touchUpInside)
    }
    func onStar(sender:UIButton) {
        // request ...
    }
}

使用时不需要关心具体逻辑，只要传入id就可以了。是不是比MVC写法更加的聚合？如果你说要在多平台复用，那么可以稍微改下，将逻辑部分改为策略模式，将创建改为工厂方法，这是题外话了。

所以接下来要忘掉所有所掌握的架构的知识，来看待这些问题，就如同张无忌学习太极剑法一样。

从结构上看的MVC

我们先举一个非常简单的例子，登录页面。

-----------------------
|                     |
| name:     [_______] |
| password: [_______] |
|     [Login]         |
|                     |
-----------------------

基本功能是校验用户名密码，和登录。

那么我们想当然的就可以明白，所需要的两个方面：

class User {
  var name: String?
  var password: String?
}

class View: UIView {
  var nameTextField
  var passwordTextField
  var loginButton
}

那么这两者之间之间的交互逻辑呢，全部丢到一个第三方类中处理，这也就是我们的MVC结构中的Controller。

所以可以了解到，MVC是最符合我们了解一项功能的思维方式，所看到的东西抽象成view，所需要保存的数据结构抽象成model，那么剩下的所有东西都被丢到了controller中。这种方式非常容易理解，一个刚入门的新手也能很容易开始编码。但这也是噩梦的一个开始。

我相信大家所经历过的项目中，肯定一些controller超过1k行，甚至更多的，谁都不想去碰一下这类代码。这就是把其他东西全部丢进一个垃圾桶的缘故。最可悲的是这个垃圾桶很少会有人去清理，导致垃圾越来越多。

解决MVC中C的问题

大家所说的Massive Controller的问题其实也很好解决，也有很多人来论述这种问题。

基本思路是细化MVC，将结构变成C-[MVCs]。比如上面可以拆分为

class NameController {
  var textField
  func validate() -> (Bool, Error)
}
class PasswordController {
  var textField
  func validate() -> (Bool, Error)
}
class LoginController {
  var button
  func login()
}
class LoginViewController: UIViewController {
  let nameController: NameController
  let passwordController: PasswordController
  let loginController: LoginController
}

注意Controller仅仅是一个概念上的划分，并不等于UIViewController。

如果是列表型可以参考DDComponent或者IGListKit的做法。

按照这种思路，我相信完全解决这类的问题。但是这样需要有经验的人士，或者在重构的时候进行拆分。

总的来说，MVC是一个非常简单，非常容易理解的架构。苹果选择MVC作为官方推荐架构应该也是有他的道理，毕竟要兼顾所有程序员，并且还要让大家能够容易的交流。但是要做好MVC也需要有一定的经验和思考。

从TDD来看MVP

好，让我们忘了上面所说的东西，同样做一个登录的功能，但是这次我们从TDD的思路来进行。

首先，界面层是比较容易变化的，而且也是难以被单元测试的，亦或者说白盒测试view是没有什么意义的。其次数据层，单纯的测试model也没有特别大的意义，除非涉及到存储等这些功能。那么我们需要测试哪些东西呢，可以测试哪些东西呢，当然是我们的业务逻辑。

那么我们来理一下登录页面的业务逻辑

1
2
3

func validateName(name: String) -> (Bool, Error)
func validatePassword(password: String) -> (Bool, Error)
func login(name: String, password: String)

然后可能有些内容需要更新回视图

1	func applyView(view: UIView)

那么以上的内容我们称为Presenter

protocol LoginView {
  var name: String?
  var password: String?
}

class Presenter {
  var user: User
  var view: LoginView

  func validateName() -> (Bool, Error)
  func validatePassword() -> (Bool, Error)
  func login()
  func applyView()
}

这样就顺理成章的拥有了MVP的模式，那么UIViewController属于哪一层呢。按照我们测试的思路，UIViewController代表的是视图的行为，是不可测试的，当然就是属于View层的了。

从上面可以看出来，所谓的P特别像View-Model，其实两者可以说就是同一个概念。

MVP中P的问题

首先，我看了很多人的文章，他们理解并不一致，都有部分的偏差，哪些属于P，P的概念也可大可小。虽然这种偏差并不影响这个架构的实现，但是让人感觉一种为了实现这种架构而实现的味道。而单纯的实现MVP并没有任何意义。

然后，MVP对人员的要求太高了。必须大家都是以测试优先来思考问题，而TDD本身就是一件非常困难的事情，对于整个团队的要求也非常高。

还有，MVP增加的代码量太大了，因为很多事件和逻辑都经过了一层转发，各个模块间的交互也增加了。

同样MVP也会遇到Massive Presenter的问题，解决方式与MVC也是类似的。

MVC与MVP

那么Controller与Presenter的差别是什么呢？可以说如果代码写的好，两者几乎是一样的，仅仅是我们看问题的角度变化。当我们看问题的角度不一样时，所写的代码与逻辑就会产生差异，这种差异可能并没有我们想象的那么大，但在白盒测试这个环节上却是致命性的。

是否需要使用MVP结构，个人觉得很多情况下并不需要MVP，在结构良好的MVC中，完全可以解决大部分问题。在MVC中出现的一些问题，并不是单纯使用MVP就能解决的。

那么MVC和MVP能否结合使用？这个就像解决Massive Controller的方案一样，C-[MVPs]应该是较好的一种结合使用方式。

使用MVP改写StarButton的例子

protocol StarView: NSObjectProtocol {
    var stared: Bool { get set }
}

class StarPresenter {
    var id: String
    weak var view: StarView?
    init(id: String, view: StarView) {
        self.id = id
        self.view = view
    }

    @objc func star() {
        Request.request {
            if let view = view {
                view.stared = view.stared
            }
        }
    }
}

class StarButton: UIButton, StarView {
    var id: String
    private var presenter: StarPresenter!

    var stared: Bool {
        get {
            return self.isSelected
        }
        set {
            self.isSelected = newValue
        }
    }

    init(id: String) {
        self.id = id
        super.init(frame: .zero)
        presenter = StarPresenter(id: id, view: self)
        self.addTarget(presenter, action: #selector(StarPresenter.star), for: .touchUpInside)
    }
}

可以感受下，这种方案和策略模式其实是非常类似的。不同点是MVP把界面更新这一步逻辑也移到了P中，对于白盒测试的可测性也更高。

最后

从TDD的角度来看MVP，的确和MVC有着很大的不同，但是这些不同并不是单纯的代码上，而是思考的方式上，如果用这种思想去写MVC，我相信最后的结果和MVP也会趋于一致，所以请忘了我上面的胡诌。