二、为对象创建Fa?ade外观模式
在实际项目中,需求是经常变化的,因此,终端返回的JSON数据格式也是如此。如果你的视图和下层的数据模型是紧耦合的,那么这是一种痛苦。有鉴于此,我为所有的对象都创建getter和setter函数。
此模式使用较广。如果任何底层的数据结构发生了变化,那么视图层无需随之更新;你会有一个数据访问点,所以你不太可能忘记做深度复制,编写的代码将会更易于维护和调试。此模式的缺点在于它可能会导致模型或集合有一点点膨胀。
下面我们看一个例子来阐明此模式。假想我们有一个Hotel模型,它包含了rooms和当前有效的rooms,而且我们希望可以通过床位大小来获取rooms。
-
var Hotel = Backbone.Model.extend({
-
defaults: {
-
"availableRooms": ["a"],
-
"rooms": {
-
"a": {
-
"size": 1200,
-
"bed": "queen"
-
},
-
"b": {
-
"size": 900,
-
"bed": "twin"
-
},
-
"c": {
-
"size": 1100,
-
"bed": "twin"
-
}
-
},
-
-
getRooms: function() {
-
$.extend(true, {}, this.get("rooms"));
-
},
-
-
getRoomsByBed: function(bed) {
-
return _.where(this.getRooms(), { "bed": bed });
-
}
-
}
-
});
现在我们假设明天你要发布项目,但你发现终端开发者忘记告诉你rooms的数据结构发生了修改。你的代码现在看起来会像下面这样:
-
var Hotel = Backbone.Model.extend({
-
defaults: {
-
"availableRooms": ["a"],
-
"rooms": [
-
{
-
"name": "a",
-
"size": 1200,
-
"bed": "queen"
-
},
-
{
-
"name": "b",
-
"size": 900,
-
"bed": "twin"
-
},
-
{
-
"name": "c",
-
"size": 1100,
-
"bed": "twin"
-
}
-
],
-
-
getRooms: function() {
-
var rooms = $.extend(true, {}, this.get("rooms")),
-
newRooms = {};
-
-
-
_.each(rooms, function(room) {
-
newRooms[room.name] = {
-
"size": room.size,
-
"bed": room.bed
-
}
-
});
-
},
-
-
getRoomsByBed: function(bed) {
-
return _.where(this.getRooms(), { "bed": bed });
-
}
-
}
-
});
我们仅修改了一个函数,以便将Hotel的结构转变为应用程序所期望的结构,以便整个应用程序仍然能像我们所预期的那样工作。如果这里没有getter函数,我们很可能不得不为rooms的每个访问点进行代码修改。理想情况下,你会修改所有函数,以适应新的数据结构,但如果你有项目发布的时间压力,此模式可以为你节省时间。
顺便说一句,此模式既可以被认为是Facade装饰模式,因为它隐藏了创建对象复制的复杂性,也可以认为是Bridge桥接模式,因为它可以用于将数据转换为所期望的格式。
最佳实践是对任何对象都使用getters 和setters 函数。
三、不通过服务器存储数据
尽管Backbone.js有模型和集合映射到RESTful端点的规则,有时候你可能会花大量时间查找你想要的存储在服务器端的数据或集合。
有一些关于Backbone.js的文章,描述了此模式。下面让我们一起来快速看一个小例子。假设你有一个ul元素列表。
-
<ul>
-
<li><a href="#" data-id="1">Onea>li>
-
<li><a href="#" data-id="2">Twoa>li>
-
. . .
-
<li><a href="#" data-id="n">na>li>
-
ul>
列表有200项,当使用者点击列表中的某项时,选择的项变成被选中状态:
-
var Model = Backbone.Model.extend({
-
defaults: {
-
items: [
-
{
-
"name": "One",
-
"id": 1
-
},
-
{
-
"name": "Two",
-
"id": 2
-
},
-
{
-
"name": "Three",
-
"id": 3
-
}
-
]
-
}
-
});
-
-
var View = Backbone.View.extend({
-
template: _.template($('#list-template').html()),
-
-
events: {
-
"#items li a": "setSelectedItem"
-
},
-
-
render: function() {
-
$(this.el).html(this.template(this.model.toJSON()));
-
},
-
-
setSelectedItem: function(event) {
-
var selectedItem = $(event.currentTarget);
-
-
$('#items li a').removeClass('selected');
-
selectedItem.addClass('selected');
-
return false;
-
}
-
});
-
现在我们能很容易的判断被选中的项,并且我们没有必要通去遍历列表。而且,如果列表非常大,遍历会是一个巨大的开销。因此,当用户点击了列表项后,我们应该存储被选择了的项。
-
var View = Backbone.View.extend({
-
initialize: function(options) {
-
-
this.model.on('change:items', this.render, this);
-
},
-
-
template: _.template($('#list-template').html()),
-
-
events: {
-
"#items li a": "setSelectedItem"
-
},
-
-
render: function() {
-
$(this.el).html(this.template(this.model.toJSON()));
-
},
-
-
setSelectedItem: function(event) {
-
var selectedItem = $(event.currentTarget);
-
-
$('#items li a').removeClass('selected');
-
selectedItem.addClass('selected');
-
-
this.selectedItemId = selectedItem.data('id'));
-
return false;
-
}
-
});
现在我们可以很容易的确定哪些项被选中了,并且我们无需遍历DOM模型。此模式对于存储外部数据来说非常有用,请记住,你可以创建不需有端点相关联的且存储外部视图数据的模型和集合。
此模式的缺点是如果你存储了外部数据到你的模型或集合,它们不能真正遵循RESTful架构,因为它们不能完美的映射Web资源;另外,此模式可能会引起对象的膨胀;如果端点是严格接受JSON格式,那么它可能会引起一些烦恼。
你或许会问自己,“我如何确定我是否应该把外部数据放进视图或者放进模型?”。如果你为呈现添加了额外的属性,例如容器的高度,那么我们把它添加到视图。如果此属性跟下层的数据模型有一定的关系,然后你想把它放进模型。总之一句话,根据实际的需求进行判断。
阅读(2474) | 评论(0) | 转发(0) |