由后端来类比前端设计的思考
有这样一句话被提起：
前端也有 MVC，DOM 树就是这个 M，CSS 就是这个 V，至于 C，非 JavaScript 莫属。
很高兴团队中有越来越多的人能够跳出某种语言、某种平台的局限性，站到抽象的层次上思考一些设计上的问题。在我的印象中，似乎前端开发总是容易给人以随意、混乱的感觉，可真的是前端技能不容易掌握吗？
大学里 Java 课程正儿八经学了 3 年，JavaScript 只字未提，只是课余时间凭借着兴趣自学，加起来也就两三个月。
前端代码更加灵活，无论是 HTML、JavaScript 还是 CSS，似乎任何一个初学者都可以轻松入门。可是越是看似简单的东西，就越难以精通地掌握，没有好的设计来引导，如果技能不过硬，很容易陷入混乱的困顿之中。
回到标题，来看看怎么从后端设计来类比前端设计。
一、模型和业务逻辑的分离：
写后台代码，模型层是很容易划分出来的，模型的建立是整体设计的第一步，美工在设计页面时，最关注一个页面最宏观的盒子模型；而 Service 层，适合存放业务逻辑，它们可以做到无状态和池化的。
前端开发呢，当 JQuery 或类似的框架出现以后，DOM 模型就可以完全和业务方法分离开了，通过这样美妙的绑定代码来完成关联和解耦：
$("#userName").click(function(){
……
}); 二、让视图层独立：
通常不要使用内联 CSS 和嵌入 CSS，视图层要让经验丰富的美工管理起来。
三、找到一个合适的切面来做接口层：
还是这几行代码：
$("#userName").click(function(){
……
}); 我们来换一个角度思考：
userName 就好像是 Java 中的接口，click 就好比是接口中的方法，如果这两个东西是既定不变的，接口的实现类当然可以随意更换了啊。
这个让我想起了 Spring 的 IoC，把对象的管理和控制权交给容器去完成—— 那么在前端，就把这个权利交给了 JQuery 的绑定逻辑去完成。
如果功能类似的页面，要求更换几套不同的效果，那么保持一个清晰的接口层，围绕接口层去完成不同的实现模板，将是一个值得尝试的方式：
//实现类一：
$("userName").click(function(){
alert("U Click Me"); //模板一的实现
});
……
//实现类二：
$("userName").click(function(){
$("userTypeFont").attr("color","RED"); //模板二的实现
});
…… 在这种情形下，接口层 DOM 的 id 和职责方法都被固定下来，开发人员可以按照接口开发、美工可以按照接口层在盒子模型中完善页面设计、测试可以按照接口来写自动化用例，这一切可美好多了！
四、针对接口来编排业务逻辑：
第三条已经建立了合适的接口层，那么相对固定的界面效果和逻辑，就可以通过桥接模式下对接口的引用来完成了。即便更换了关系到展现效果的模板，核心 JavaScript 都不会变化。
五、分离模板和数据：
模板和数据的整合，似乎是后端应该做的事，例如 FreeMarker 模板和数据的整合，最终形成页面。
现在，这件事情在前端也可以完成了：
（1）生成相对静态的模板：
<div id="userName">${user.userName}</div>（2）Ajax 获取到模板的数据：
{"user":{"name":"James"}} （3）浏览器端聚合，搞定最后的页面：
<div id="userName">James</div> 这样做的静态模板的很容易在缓存中命中，而数据的生成也非常灵活，最后，聚合是在客户端完成的，这方面对服务端没有压力，因此性能往往非常高。
六、归纳一下：抽象，是软件设计的核心艺术。即便前端设计，也一样。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
×Scan to share with WeChat