红包项目总结---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仍会打进包里。　　　

　　　　　　　　

源码

　　github上下载

意义
  MVC版红包虽然进行了强力解耦，对wap端来说，解耦却有点过了，可也并不是针对SPA推出。因为，Augalar是现在SPA的霸主。但是，MVC设计统治后台，前端。一旦涉及多人协作，它是不二之选。它只会因为使用语种(java php flex js)，环境(浏览器、虚拟机)的不同，而变形。本质不会变。
 此版是阐述我对MVC的理解。希望给大家有所帮助，并不是要推广它。