① 单个页面的样式全部写在一个文件中，比如list里面所有模块对应的是list.css ② 模块之间采用观察者模式观察数据实体变化，以数据为媒介通信 ③ 一般来说业务模块不可重用，如果有重用的模块，需要分离到common目录中，因为我们今天不考虑common重用，这块暂时不予理睬

这里有些朋友可能认为单个模块的CSS以及image也应该参与独立，我这里不太同意，业务页面样式粒度太细的话会给设计带来不小的麻烦，这里再以通俗的话来说：尼玛，我CSS功底一般，拆分的太细，对我来说难度太高......

不好的这个事情其实是相对的，因为不好的做法一般是比较简单的做法，对于一次性项目或者业务比较简单的页面来说反而是好的做法，比如这里的业务逻辑可以这样写：

1 define(['AbstractView', 'list.layout.html', 'list.html', 'BusModel', 'BusStore', 'UICalendarBox', 'UILayerList', 'cUser', 'UIToast'], 2 function (AbstractView, layoutHtml, listTpl, BusModel, BusStore, UICalendarBox, UILayerList, cUser, UIToast) { 3 return _.inherit(AbstractView, { 4 propertys: function ($super) { 5 $super(); .events = { 'click .js_next_day': 'nextAction', 'click .js_bus_list li': 'toBooking', 'click .js_show_calendar': 'showCalendar', 'click .js_show_setoutdate': 'showSetoutDate', 'click .js_show_setstation': 'showStation', 'click .js_show_arrivalstation': 'showArrivalStation', 'click .js-list-tip': function () {} 19 }; 20 }, initHeader: function (t) { }, initElement: function () {}, 25 showSetoutDate: function () {}, 26 showStation: function () {}, 27 showArrivalStation: function () {}, 28 showCalendar: function () {}, 29 preAction: function (e) {}, 30 nextAction: function () {}, 31 toBooking: function (e) {}, 32 listInit: function () {}, 33 bindScrollEvent: function () {}, 34 unbindScrollEvent: function () { }, 35 addEvent: function () { 36 this.on('onShow', function () { .listInit(); }); 41 this.on('onHide', function () { 42 this.unbindScrollEvent(); 43 }); 44 } 45 }); 46 });

根据之前的经验，如果仅仅包含这些业务逻辑，这样写代码问题不是非常大，代码量预计在800行左右，但是为了完成完整的业务逻辑，我们这里马上产生了新的需求。

因为我这里的班次列表，最初是没有URL参数，所以根本无法产出班次列表，页面上所有组件模块都是摆设，于是这里新增一个需求：

当url没有出发-到达相关参数信息时，默认弹出出发城市到达城市选择框

于是，我们这里会新增一个简单的弹出层：

这个看似简单的弹出层，背后却隐藏了一个巨大的陷阱，因为点击出发或者到达时会出城市列表，而城市列表本身就是一个比较复杂的业务：

于是页面的组成发生了改变：

① 本身业务逻辑约800行代码

② 新增出发到达筛选弹出层

③ 出发城市页面，预计300行代码

而弹出层的新增对业务本身造成了深远的影响，本来url是不带有业务参数的，但是点击了弹出层的确定按钮，需要改变URL参数，并且刷新本身页面的数据，于是简单的一个弹出层新增直接将页面的复杂程度提升了一倍。

于是该页面代码轻轻松松破千了，后续需求迭代js代码量破2000仅仅是时间问题，到时候维护便复杂了，页面复杂无规律的DOM操作将会令你焦头烂额，这个时候组件化开发的优势便得以体现了，于是下面进入组件化开发的设计。

这次的代码依赖于blade骨架，包括：

① MVC模块，完成通过url获取正确的page控制器，从而通过view.js完成渲染页面的功能

② 数据请求模块，完成接口请求

全站依赖于javascript的继承功能，详情见：【一次面试】再谈javascript中的继承，如果不太了解面向对象编程，文中代码可能会有点吃力，也请各位多多了解。

总体业务架构如图：

框架架构图：

下面分别介绍下各个模块，帮助各位在下文中能更好的了解代码，首先是基本MVC的介绍，这里请参考我这篇文章：

其实控制器可谓是变化万千的一个对象，对于服务器端来说，控制器完成的功能是将本次请求分发到具体的代码模块，由代码模块处理后返回字符串给前端；

对于请求已经来到浏览器的前端来说，根据这次请求URL（或者其它判断条件），判断该次请求应该由哪个前端js控制器执行，这是前端控制器干的事情；

当真的这次处理逻辑进入一个具体的page后，这个page事实上也可以作为一个控制器存在......

我们这里的控制器，主要完成根据当前请求实例化View的功能，并且会提供一些view级别希望单例使用的接口：