通过页面静态化促进后端逻辑的可重用性

这里的页面静态化是指前端的一个页面（或页面中的一个元素）使用纯静态html，然后通过ajax读取后端的json/xml数据，以获得动态内容。 它的反面是普通的MVC技术：用户请求发出后，先让后端取得数据，再直接渲染到jsp/asp/php等动态页面脚本上。

后端逻辑的可重用性是指：新建一个页面（或页面中的一个元素）时，只需新写View层代码(html或jsp)，后端可以不改或者改得很少。

跟普通MVC相比，页面静态化方案可以使后端逻辑更容易重用。这是因为：

1. 静态化方案中的数据模型职责往往比较单一，而普通MVC中的数据模型中可能掺杂页面逻辑相关的东西，导致不可重用。

2. 静态化方案天然支持“固定Controller + 不定View”的组合，Controller只须写一次；而普通MVC在这方面却有点弱。

3. 通过局部刷新机制，静态化方案允许“一个View由多个Controller同时提供数据”，而普通MVC基本只能用单个Controller，导致这个Controller的弱内聚和臃肿。

举例来说，要展现“某次航班的详情”，普通MVC的实现可能是这样：

	Model (数据结构)	Controller (/detail.do)
普通MVC	FlightDetailVO: ID 路线 起飞时间 余票数 订购按钮的css class名 …	1. 从航班数据库查出各种BO再拼装出各种航班信息 2. 按余票情况决定订购按钮的css class名及其它页面信息 3. 组合出FlightDetailVO对象 4. 把请求移交给flight_detail.jsp，渲染FlightDetailVO对象

一段时间后，来了个新需求： 要做一个只读的页面flight_detail_readonly.jsp，也要展示航班详情，但没有“订购”等按钮。 为了重用原来的Controller + Model，你在后端要做的改动有：

1. 根据请求来源，决定是否要在FlightDetailVO中填充“订购按钮的CSS名”等相关信息

2. 根据请求来源，决定是去flight_detail.jsp还是flight_detail_readonly.jsp

而如果一开始对“航班详情”使用是静态化方案，问题就会更容易解决。

	Model (数据结构)	页面Controller (/detail.do)	数据接口Controller(/detail.json)
Html+json/xml	FlightDetailVO: ID 路线 起飞时间 余票数	按余票情况决定订购按钮的css class名及其它页面信息	1. 从航班数据库查出各种BO再拼装出各种航班信息 2. 组合出FlightDetailVO对象 3. 将对象序列化为json然后输出为http response

对于新需求“做一个只读的航班详情页面”，只须让新页面用ajax访问已有的/detail.json接口，后端不必做任何改动；即使新页面有自己的页面逻辑，需要对应的页面Controller，我们也只需新增这个Controller，而不必修改已有的任何后端代码，这也符合开放封闭原则(OCP)：宁可加代码，不要改代码。

如果再来一个需求“在主页嵌套航班777的详情信息”，那两种方案的区别就更明显了。普通MVC方案中，需要在HomepageController中把FlightDetailVO相关的逻辑全部移植过来导致弱内聚，如果这个需求下线，又要把移植过来的代码又去掉。而在静态化方案中，仍只需让homepage.jsp用ajax访问已有的/detail.json接口，后端不必做任何改动。

由于前后端的彻底分离，后端逻辑的跨应用重用也变得方便了。如果你的网站由多个频道组成且不同频道由不同团队维护，当你们部门的频道需要嵌入另一个频道的信息时，你甚至不用打扰他们（响应很慢，你懂的）；你只须把他们的jsonp接口拿到，然后自己写前端html+ajax就可以了。

当然，这里并非要建议整个网站都静态化，由于http请求数更多，它会导致服务端和浏览器的性能问题；而且如果总是要设计可重用的数据结构，开发的敏捷性也会下降。所以在使用这种方案时，要评估一下要做的东西的可重用性，权衡一下收益和得失再做决定。