再谈iOS中的MVC

1. MVC，即Model,View,Controller。概念层面都很清晰，但是真正落地到项目中时、编码时，不同的人写出的MVC架构的代码可能千差万别。其中，最关键也最有争议的，莫过于Model这一层。
2. 在iOS开发实践中，很多人将Model只是简单处理成数据模型，即简单封装映射JSON字段。网络请求-字典转模型-赋值给视图，一切似乎看起来顺理成章。然而，这样的Model并没有完全承担起MVC架构中Model这一层应该承担起的功能，继而导致了Contrller层必须替他完成未尽的责任，最后变成了Massive Controller。
3. 举个，有个订单页面，要显示下单时间，包括年月日时分秒。服务端返回了时间戳字段，Model也映射到了对应的字段，Controller也转发给了对应的View,结果View拿到手后，发现给的数据不满足业务展示需求，需要多加一部操作，时间格式转换。问题就在于，这步操作要放哪？
4. 如果我们将数据转换放在View层呢？View层中会充斥大量业务规则相关的逻辑，每个和这个字段相关的View都需要自己写一遍这种转换代码。另外，这个View绑的太死了，假如有另外一个页面和这个页面布局一样，只是数据的格式不同，也无法复用。另外，从性能上来说，大量View（比如一屏大量cell）持有类似时间转换这种对象，会影响渲染性能。
5. 如果我们将这步放在Controller层？这也许正是大多数人正在使用的。而这导致的后果也已经众所周知，臃肿的控制器，无法复用的代码，不利于单元测试等等。到这一步，很多人可能已经骂MVC垃圾，转而投向了其他架构的怀抱，比如MVVM，MVP等等，然而这真的是MVC的问题吗？
6. 根本原因还是在Model层，Model层不应该仅仅是数据模型层，完整的Model = 数据模型 + 业务模型。就像一个对象，很少有仅仅包含属性的对象，对象 = 属性 + 方法。如果你认同这个说法，那么接下来的思路就很清晰了。 首先，我们在Model层加一个业务属性字段，对应View所需的订单时间。然后，我们还要加方法，包括请求订单数据的接口，修改订单数据的接口。基于这样的封装后，MVC中各自的职责就相当明确了，Model提供数据，Controller只是转发相关的Model给对应的View，而View拿到数据后直接展示。那么到这里是否就结束了呢？
7. 想象一下，业务逻辑是充满变数了，在实践中，我们可能要不断修改和增加业务字段，同时我们会发现网络映射的基础字段几乎是不变的。此外，部分项目可能是采用私有库的方案，很多项目是共享基础的数据模型的。所以在项目初期，我们会接受胖Model，但逐渐的，我们会倾向于分离数据模型和业务模型，数据模型下沉为公共库，业务模型跟着项目走。看到这里，你可能会发现，拆出来的业务模型，其实就是所谓的ViewModel.ViewModel以Model为输入，以能被View直接使用的字段为输出，这样，控制器直接把相关的VM注入V中就可以了。