之前了解架构的时候，虽然能够看得懂MVC和MVP这些概念，但是却没有实感，总感觉很多地方其实并没有那么的明确。最近想起之前的讨论TTD的文章，忽然想到，为什么不从另一个角度来看待这两中模式呢，所以忽然醒悟，现在来讲讲这两种模式解决的问题。
无法解决的单元测试
最近在开发过程中，虽然大部分场景都比较简单，逻辑也非常清晰，但是也有部分场景的逻辑比较多，一些隐藏逻辑还难以通过造数据来进行测试，自然QA也基本覆盖不到这种测试场景，那么自然想到了单元测试，但是以目前我们项目的架构来说，单元测试基本不可能，业务逻辑、事件界面等揉合在一起，无从下手。
我们目前的架构来看，并不差，无论从实用性，易用性和复用性上来说。但是网上众多大神都极力推崇MVP和MVVM，我一直都没有太明白别人所说的优点真的如此神奇吗？直到最近想要对部分业务复杂的页面做单元测试，然后从TDD的角度再去看这些问题，才豁然开朗，下面就来简单介绍下。
架构之间的模糊性
我们来探讨一下，现在官方推荐的MVC架构在实战中的情况，真的能够分的如此清楚吗？
也有很多人把这种架构表示为这样：
--------------------- ---------
| 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也没有特别大的意义，除非涉及到存储等这些功能。那么我们需要测试哪些东西呢，可以测试哪些东西呢，当然是我们的业务逻辑。
那么我们来理一下登录页面的业务逻辑
func validateName(name: String) -> (Bool, Error)
func validatePassword(password: String) -> (Bool, Error)
func login(name: String, password: String)
然后可能有些内容需要更新回视图
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也会趋于一致，所以请忘了我上面的胡诌。
