红包项目总结---MVC版
起因： 针对传统版的明显缺陷做优化。主要是提升可维护性。
效果
线上： 未发布
线下：http://10.27.5.1/svn/FED/code/hongbao/year-end hb-fact-mvc项目。参照传统版运行方式。
亮点
观察领群红包首页代码
原因
采用了自研框架。
项目关键点
响应式 沿袭传统版
应用程序框架
特征： 框架约束业务渲染，MVC标配类显式分层。
架构: 自研框架wap.js实践
MVC标配：
service类： wap.js约束
模块化框架： sea.js。 选择sea.js，不选择require的原因是，它压缩后只有几K。require几十K。sea有很多中文文档，容易剖析源码。
DOM库： zepto
组件化：接口束缚流程。子类继承组件wap-cmp.js类。接口按顺序调用流程方法。
异常： dao层 zepto自带error。
日志：wap.js 访问模板链数据为空时抛出warn日志
适应场景 2人上。SuNing M站。小项目均可以使用，理解MVC。
优点 可维护性强。
缺陷 前期需做足对框架的优化，源码剖析。 性能瓶颈依赖自研框架的水准。（打包很痛苦，这个不算明显的缺陷吧，解决了，照着流程做就OK）
集成方案
spm
未打包成功，陷在合并那里。
fis无法合并seaJS。原因是，只有seaJS知道依赖了哪些类。spm支持合并，则通过require字面量去分析依赖，它不支持seaJS的别名，影响我的设计。至于张云龙提供的松鼠，基于fis封装的模块化框架+集成方案一整套东西，还未尝试。
性能 无
项目明显缺陷
1，未有堪比传统版的打包方案
2，引入seajs，自研wap.js 在提升可维护性的同时，均会对性能造成损伤。
缺陷处理
打包可以解决。
性能方面，针对WAP界面的内存下，网速下的实际情况。应对可维护性，代码管理采取’优雅降级‘的办法，来提升性能。推出实用版。
1，去掉模块依赖，采用JSON类来替代模块。在源码hb-fact-wapmvc项目里打开getgrouphb.html里可以看到
如果对性能仍不满意，还可以将MVC标配基类的继承改为组合，甚至去掉。
不采用模块化框架，又采用MVC设计，带来的明显问题就是，加载的JS，看上去10几个太多。实际上我们可以自研一种模块加载，对现有的集成方案fis，gulp等进行改造。达到开发时采用CMD模块化，打包后，去模块化。页面合并JS，合并CSS的效果。
seaJS+spm做不到。因为seaJS仍会打进包里。
源码
意义
MVC版红包虽然进行了强力解耦，对wap端来说，解耦却有点过了，可也并不是针对SPA推出。因为，Augalar是现在SPA的霸主。但是，MVC设计统治后台，前端。一旦涉及多人协作，它是不二之选。它只会因为使用语种(java php flex js)，环境(浏览器、虚拟机)的不同，而变形。本质不会变。
此版是阐述我对MVC的理解。希望给大家有所帮助，并不是要推广它。
