My App 之 MVC 变种模式
在App 文件划分的时候，实际上已经考虑好我们的基本架构是怎样的，整体来说是 MVC 或者说MVC 的变种，整体来说还是根据项目的的大小和具体需求来定。而我个人最近也在想这块的问题，特此一步一步理一下。
MVC （一）
MVC （一）
- Controller ： 干了超多事情, 各种事件
- View： 呈现视图事件
- Model：数据的Model 化
- Other： 管理类以及一些工具
此时如果业务一下子复杂之后，Controller 里面承担的工具确实会太多了，会太臃肿啦，至少维护起来是尴尬的，所以此处相对来说适用于小型项目，项目大一点就要将其 Controller 里的部分抽取出来。
MVC （二）
MVC （二）
此处相对于 MVC（一） 来说，就是将 请求事件单独再抽离出来，让 Contoller 只要通过一个回调的形式请求数据，然后达到 轻 Controller 的目的，我认为相对来说这又进步的。
MVC （三）
MVC （三）
- Controller ： 各种逻辑事件和跳转
- View： 需要呈现的视图
- ViewModel: 数据的请求
- Api: 网络请求的配置
- Model：数据的Model 化
- Other： 管理类以及一些工具
这是我们之前尝试过的一种另类的 MVVM 变种类型，就是 ViewModel 不仅充当请求的处理还有部分代理的实现：
- 类似 UITableView的代理，方便之处就是类似 UITableView 中很多代理事件直接在其中实现了，无需再返回到ViewController 中去处理。
- 像 UITableView 中的 Cell 和 HeaderView 直接在 ViewModel 中处理
- 以及类似空页面的代理也可以直接放在 ViewModel 中，这样就让 ViewModel 在有些时候成为 列表页面的扩展类的感觉，但确实很方便。
然而最大的问题就是，可能ViewModel 和 ViewController 中里面实现是事件类型不统一。
例如：
- 跳转事件即出现在 ViewModel 中，也可能出现在 Controller 里。
- 部分自定义View 即直接在 ViewController 中呈现，也可能在 ViewModel 中呈现。
总的说来，就是相同的事件没能在同一个地方处理，显得有点乱，不利于后期的开发和维护。
MVC （四） 就是为了适当的解决这些问题而产生的。
MVC （四）
MVC （四）
- Controller ： 可以说主要用于跳转事件
- View： 更新和呈现视图，所有视图都在整个里面，相当于 self.view。
- ViewModel: 数据的请求，以及部分逻辑事件
- Api: 网络请求的配置
- Model：数据的Model 化（转化）
- Other： 管理类以及一些工具
这是我们组长按照他的思路逐一实践出来，虽说不是很完美，暂时来说还是适用我们项目的。
注意此处的 View 是相当于 ViewController 中的 self.view 的，所有的视图都以其 SubView 呈现，这样也方便后期的任意添加 SubView, 当然此处很多 SubView 是自定义的，需要再单独抽离出来的。
当然它也是有一些问题的，例如最大的问题就是 可能 View 中会比较臃肿，里面的事件比较多。
实际上，我在想后两种应该属于 MVVM 的变种，但是又有点不恰当，不知道怎么命名，但无论如何都是以 MVC 转换过来的，所以暂且这么归类。
至于具体项目用哪一个架构模式呢？我个人认为中小型项目是侵向第二种模式的，但我们现在的项目确是适用 第四种模式的，虽说第四种模式实践的还不多...
另外真心觉的架构模式这块要看自己项目的业务逻辑和大小的，继续发现中...
如有朋友对这块有好的意见和想法，欢迎一起探讨！
