对于移动端的页面来说，一个页面对应着一个View.js，即上面的业务View，其中model可以完全的分离出来，如果以AMD模块化的做法的话，View.js的体积会非常小，而主要逻辑又基本拆分到了Model业务中，controller做的工作由于前端模板的介入反而变得简单

不足之处，便是所有的controller全部绑定到了view上，交互的触发点也全部在view身上，而更好的做法，可能是组件化，但是这类模块包含太多业务数据，做成组件化似乎重用性不高，于是就有了业务组件的诞生。

所谓业务组件或者公共频道都是网站上了一定规模会实际遇到的问题，我这里举一个例子：

最初我们是做机票项目于是目录结构为：

blade 框架目录

flight 机票业务频道

static 公共样式文件

然后逐渐我们多了酒店项目以及用车项目目录结构变成了：

blade 框架目录

car 用车频道

hotel 酒店频道

flight 机票业务频道

static 公共样式文件

于是一个比较实际的问题出现了，最初机票频道的城市列表模块以及登录模块与常用联系人模块好像其他两个频道也能用，但是问题也出现了：

① 将他们抽离为UI组件，但他们又带有业务数据

② 其它两个频道并不想引入机票频道的模块配置，而且也不信任机票频道

这个时候便会出现一个叫公共频道的东西，他完成的工作与框架类似，但是他会涉及到业务数据，并且除了该公司，也许便不能重用：

blade 框架目录

common 公共频道

car 用车频道

hotel 酒店频道

flight 机票业务频道

static 公共样式文件

各个业务频道引入公共频道的产品便可解决重用问题，但这样也同时发生了耦合，如果公共频道的页面做的不够灵活可配置，业务团队使用起来会是一个噩梦！

于是更好的方案似乎是页面模块化，尽可能的将页面分为一个个可重用的小模块，有兴趣的朋友请到这里看看：

【前端优化之拆分CSS】前端三剑客的分分合合

【shadow dom入UI】web components思想如何应用于实际项目

关于系统优化的建议我之前写了很多文章，有兴趣的朋友可以移驾至这里看看：

浅谈移动前端的最佳实践

我这里补充一点业务优化点：

① ajax请求剥离无意义的请求，命名使用短拼

这条比较适用于新团队，服务器端的同事并不会关注网络请求的耗时，所以请求往往又臭又长，一个真实的例子就是，上周我推动服务器端同事将城市列表的无意义字段删除后容量由90k降到了50k，并且还有优化空间！！！

② 工程化打包时候最好采用MD5的方式，这样可做到比较舒服的application cache效果，十分推崇！

③ ......

半年了，项目由最初的无趣到现在可以在上面玩MVC、玩ABTesting等高端东西了，而看着产品订单破一，破百，破千，破万，虽然很累，但是这个时候还是觉得是值得的。

只可惜我厂的一些制度有点过于恶心，跨团队交流跟吃屎一样，工作量过大，工资又低，这些点滴还是让人感到失望的。

好了，抱怨结束，文章浅谈了一些自己对移动端从0到1做业务开发的一些经验及建议，没有什么高深的知识，也许还有很多错误的地方，请各位不吝赐教，多多指点，接下来时间学习的重点应该还是IOS，偶尔会穿插MVVM框架（angularJS等）的相关学习，有兴趣的朋友可以一起关注，也希望自己尽快打通端到端吧，突破自身瓶颈。

最后，我的微博粉丝及其少，如果您觉得这篇博客对您哪怕有一丝丝的帮助，微博求粉博客求赞！！！