时隔两年，再次回顾Reader Prime项目的重构历程，有一点十分坚定，就是对于独立开发者而言，一个好的构架和项目整体的高扩展性，是降低维护成本的必备条件。
虽然在编写mvc-base构架之初，自己的构架的成型规模和概念还都理解不深刻的时候，一边开发，一边扩展和修改，甚至推翻部分构架的模式很让人痛苦，但这一切在后来看都是十分值得的。
我本人也因为经历了人生第一次封装一个概念中间层，对软件工程有了一个更深层的理解。真正用到的东西无非两点，一是对适用语言和框架的深刻理解，这里指的就是ObjC和CocoaTouch框架；二是对设计模式的贯彻实践。
在这个基础上，Prime维护也告一段落，最近在中国区被下架，推动我不得不将工作重心迁移到下一个项目中，为了新项目作准备，我也在mvc-base的经验基础上，重新制作一个更自洽的VIPER类型框架viper-base。
VIPER类构架的思想，已经在业内讨论了好几年，我简单表述一下我自己的理解。首先是VIPER五个部分，在CocoaTouch的框架中，应该从什么现有类型中演绎。
| VIPER中概念 | 描述 | CocoaTouch中的类 | 职责 |
|---|---|---|---|
| View | 视图 | UIView,UIControl | 界面绘制和重用 |
| Interactor | 交互器 | 无 | 逻辑运算 |
| Presenter | 展示器 | UIViewController | 处理交互和相应事件 |
| Entity | 数据实例 | NSObject, NSManagedObject | 数据承载 |
| Router | 路由 | 无 | - |
简单说明一下，Interactor扮演的角色，应该是原本Apple MVC构架下，View Controller的数据处理职责，Router则是完全一个新的概念，在Apple MVC中并不存在。
这样的VIPER构架下，各个模块是各司其职的，就可以避免出现一个庞大的臃肿的类，导致解藕、扩展性极差。
mvc-base的优缺点
我已经在Github上开源了mvc-base和RSS Reader Prime全部代码，mvc-base的优点也很明显，它将原本的ViewControler拆分为View和Prsenter两部分，View负责UI布局，Presneter负责处理交互事件和数据，模块低耦合，分工明确，极有利于后期寻找功能代码位置。
但其缺点也很明显，主要一点就是Presenter 和 View 是一对一的设计，这样其实复用率仍然很低。
viper-base的挑战
最重要的挑战，就是针对mvc-base的缺点，我们如何设计出Presenter（相当于mvc-base中的View）和Interactor（相当于mvc-base中的Presenter）的交叉绑定关系。
在构架过程中，我使用了一个事件流控制的优秀框架PromiseKit，这得益于javascript的promise特性给我带来的深刻理解。
目前这个挑战还悬而未决，我在Prenseter的设计中，采取了热接口的组件方式，有利于第三方控件的快速对接和扩展。