老生常谈的一个词儿“MVC”,各种框架都会说自己是MVC、MVVC或者其他的云云,那么MVC到底是什么?我个人倾向于这是一种设计思想。将业务设计、数据访问以及请求处理或视图绘制等功能实现分离,各自进行调整时而不会产生严重的耦合问题。这是对代码可维护性、健壮性的一种保障。
在进行服务端设计的时候,Service层、Dao层及Servlet层是相互分离的,Service层仅仅处理业务逻辑,Dao也只是进行数据访问,Servlet做的更少仅处理请求并做应答。
Javascript虽然不是严格的面向对象语言,但这并不妨碍我们使用MVC的设计思想来实现功能。
之前在汉普做产品设计的时候,同组有一个做前端小伙子,据说有三年的前端开发经验,我必须承认,其编码熟练度是完全OK的,但是我并不赞同他的设计方法,就此事我们也争论过很多。残酷的事实证明了我是对的,当他的Js文件已经超过了五千行甚至八千行,存在了大量重复代码后,哪怕我们仅仅想做一个很小的功能调整,也已经变得异常困难(每次变动都需要全文搜索,逐行检查,有相互调用的时候简直要摔键盘)。
后来他跟我抱怨说,工作压力太大,不想做了。其实根源上就是代码结构的不合理导致的,这一点对于任何一个强大的开发者而言都是致命的。当重构已经变得困难,那么维护也无从谈起,倍增的额外工作给精神上造成的压力不可小觑。
Js的编写很灵活,它的灵活性为编码带来的无限的可能性,充满了未知的魅力。灵活本身就是个双刃剑,如果你对Js的解释逻辑不甚了解,那么你的每一行代码都可能存在Bug。我不建议任何人,哪怕是有着丰富工作经验的前端开发者,使用任何看似华丽简洁的语法。
能通过基础语法实现的功能,绝不用更难以迁移的语法特性代替(如果你做过跨语言平台设计,那么翻译工作可能死在特殊语法上,那时你会知道你多么的痛恨华丽的语法特性)!华丽的设计应该是模式上的美观,更好的功能延展,更强的维护性能,更清晰的逻辑结构。
所以我建议编写Js尽量以对象的方式进行设计,将方法、属性都封装在对象内部,这样不论对于代码本身的良好结构,还是团队协作时可能产生的覆盖问题,都能最大限度的提供保障。
我本身并不怎么会写Js,我更擅长将Js当作Java与Json的结合体。这里我列举自己常用的一种Js编写模式,大家也可以从网络上搜索其他朋友的建议。这是基于Jquery实现的用户登陆页的脚本,仅仅定义了基本的结构,后面章节会把实现补充进去,Jquery语法大家可以从其他途径了解,如下:
$(function () {
LoginPage.initial();
});
var LoginPage = {
initial: function () {
LoginPageMVC.View.initial();
},
urls: {
base: 'http://localhost:8080/JianZi',
login: {
url: BaseUrl + '/user',
method: 'POST',
params: {
'action': 'login',
'phone': '',
'password': ''
}
},
register: {
url: BaseUrl + '/user',
method: 'POST',
params: {
'action': 'register',
'phone': '',
'password': '',
'nickname': ''
}
}
}
};
var LoginPageMVC = {
Model: {},
View: {
initial: function () {
},
refresh: function () {
}
},
Controller: {
login: function () {
},
register: function () {
}
}
};
整个Js文件里仅有三部分,头部是Jquery的标志性语法:
$(function()){}
其次是和页面相关的全局设置,我常常会写入请求路径,初始化页面的方法调度:
var LoginPage = {
initial: function () {
},
urls: {
login: {
},
register: {
}
}
};
最后一个是和页面相关的名为MVC的对象,它包含了本页需要的数据模型、视图操作(页面的初始化、更新及其他因数据变动导致的视图更新操作)以及请求处理方法:
var LoginPageMVC = {
Model: {},
View: {
initial: function () {
},
refresh: function () {
}
},
Controller: {
login: function () {
},
register: function () {
}
}
};
整个页面的处理流畅大致如下:
so,如此简单,模式统一,维护方便,连注释都不需要多加。当然这跟项目规模和具体的应用场景有关,参加过大型项目开发的朋友应该知道规范的重要性,没有最好,只有更适合,不对此做更多讨论。