深入探索Backbone.js应用开发

5星 · 超过95%的资源需积分: 16 184 浏览量更新于2024-07-23 收藏 2.47MB PDF 举报

"《Developing Backbone.js Applications》是由Addy Osmani编写的关于Backbone.js开发的书籍，旨在深入探讨Backbone.js框架及其在构建Web应用程序中的应用。本书介绍了MVC（模型-视图-控制器）模式、MVP（模型-视图-呈现器）模式，并详细讲解了Backbone.js的基础概念，包括模型、视图、集合、路由器以及命名空间等核心组件。此外，书中还提到了Underscore库的实用函数和自动化Backbone Scaffolding等开发技巧。" Backbone.js是一个轻量级的JavaScript库，它提供了模型层的结构、视图的管理以及路由功能，帮助开发者构建复杂的单页应用（SPA）。在《Developing Backbone.js Applications》中，作者首先阐述了MVC模式的起源，从Smalltalk-80的MVC概念出发，解释了现代Web开发中MVC模式的演变。模型（Models）负责数据和业务逻辑，视图（Views）用于用户界面的展示和交互，而控制器（Controllers）则在两者之间协调。书中提到，Backbone.js中的控制器角色相对较弱，更多的职责被赋予了视图。同时，书里比较了Spine.js中的控制器与Backbone.js的不同，强调了MVC模式带给我们的组织和解耦代码的优势。接着，书讨论了MVP模式，其中呈现器（Presenter）作为模型和视图之间的桥梁，使得代码更加清晰和易于测试。在深入探讨部分，书中详细介绍了Backbone.js的核心组件： 1. 模型（Models）：用于封装数据和业务逻辑，与服务器进行数据同步。 2. 视图（Views）：负责渲染模型数据并处理用户交互，通常通过事件绑定来实现与模型的通信。 3. 集合（Collections）：是模型的集合，提供了对一组模型的操作和管理。 4. Underscore utility functions：Backbone.js依赖于Underscore.js库，提供了许多便利的辅助函数。 5. 路由器（Routers）：根据URL变化来执行特定的函数，实现了基于哈希片段的导航和历史记录管理。 6. Backbone.history：监控URL改变，确保应用可以响应浏览器的前进/后退按钮。 7. 命名空间（Namespacing）：避免全局变量污染，提高代码的可维护性。除此之外，书中还提供了一些额外的开发建议，如自动化Backbone Scaffolding工具，可以帮助快速生成基础的Backbone.js结构，从而提高开发效率。《Developing Backbone.js Applications》是学习和理解Backbone.js框架的宝贵资源，对于希望构建高效、可扩展的JavaScript应用的开发者来说，是一本不可或缺的参考书。

In the context of JavaScript frameworks that support MVC/MV*, it is worth looking

more closely at JavaScript templating and its relationship to Views.

It has long been considered bad practice (and computationally expensive) to manually

create large blocks of HTML markup in-memory through string concatenation. De-

velopers using this technique often find themselves iterating through their data, wrap-

ping it in nested divs and using outdated techniques such as document.write to inject

the “template” into the DOM. This approach often means keeping scripted markup

inline with standard markup, which can quickly become difficult to read and maintain,

especially when building large applications.

JavaScript templating libraries (such as Handlebars.js or Mustache) are often used to

define templates for views as HTML markup containing template variables. These

template blocks can be either stored externally or within script tags with a custom type

(e.g “text/template”). Variables are delimited using a variable syntax (e.g {{name}}).

Javascript template libraries typically accept data in JSON, and the grunt work of pop-

ulating templates with data is taken care of by the framework itself. This has a several

benefits, particularly when opting to store templates externally as this can let applica-

tions load templates dynamically on an as-needed basis.

Let’s compare two examples of HTML templates. One is implemented using the pop-

ular Handlebars.js library, and the other uses Underscore’s “microtemplates”.

Handlebars.js:

<h2>{{caption}}</h2>

</div>

</li>

Underscore.js Microtemplates:

<%= metadata %>

</div>

</li>

You may also use double curly brackets (i.e {{}}) (or any other tag you feel comfortable

with) in Microtemplates. In the case of curly brackets, this can be done by setting the

Underscore templateSettings attribute as follows:

_.templateSettings = { interpolate : /\{\{(.+?)\}\}/g };

A note on navigation and state

It is also worth noting that in classical web development, navigating between inde-

pendent views required the use of a page refresh. In single-page JavaScript applications,

MVC As We Know It | 7

however, once data is fetched from a server via Ajax, it can be dynamically rendered in

a new view within the same page. Since this doesn’t automatically update the URL, the

role of navigation thus falls to a “router”, which assists in managing application state

(e.g allowing users to bookmark a particular view they have navigated to). As routers

are however neither a part of MVC nor present in every MVC-like framework, I will

not be going into them in greater detail in this section.

Controllers

Controllers are an intermediary between models and views which are classically re-

sponsible for two tasks: they both update the view when the model changes and update

the model when the user manipulates the view.

In our photo gallery application, a controller would be responsible for handling changes

the user made to the edit view for a particular photo, updating a specific photo model

when a user has finished editing.

It’s with controllers that most JavaScript MVC frameworks depart from this interpre-

tation of the MVC pattern. The reasons for this vary, but in my opinion, Javascript

framework authors likely initially looked at server-side interpretations of MVC (such

as Ruby on Rails), realized that that approach didn’t translate 1:1 on the client-side,

and so re-interpreted the C in MVC to solve their state management problem. This was

a clever approach, but it can make it hard for developers coming to MVC for the first

time to understand both the classical MVC pattern and the “proper” role of controllers

in other non-Javascript frameworks.

So does Backbone.js have Controllers? Not really. Backbone’s Views typically contain

“controller” logic, and Routers (discussed below) are used to help manage application

state, but neither are true Controllers according to classical MVC.

In this respect, contrary to what might be mentioned in the official documentation or

in blog posts, Backbone is neither a truly MVC/MVP nor MVVM framework. It’s in

fact better to see it a member of the MV* family which approaches architecture in its

own way. There is of course nothing wrong with this, but it is important to distinguish

between classical MVC and MV* should you be relying on discussions of MVC to help

with your Backbone projects.

Controllers in Spine.js vs Backbone.js

Spine.js

We now know that controllers are traditionally responsible for updating the view when

the model changes (and similarly the model when the user updates the view). Since

Backbone doesn’t have its own explicit controllers, it’s useful to review the controller

from another MVC framework to appreciate the difference in implementations. Let’s

take a look at Spine.js:

8 | Chapter 1: Introduction

In this example, we’re going to have a controller called PhotosController which will be

in charge of individual photos in the application. It will ensure that when the view

updates (e.g a user edited the photo meta-data) the corresponding model does too.

(Note: We won’t be delving heavily into Spine.js beyond this example, but it’s worth

looking at it to learn more about Javascript frameworks in general.)

// Controllers in Spine are created by inheriting from Spine.Controller

var PhotosController = Spine.Controller.sub({

init: function(){

this.item.bind("update", this.proxy(this.render));

this.item.bind("destroy", this.proxy(this.remove));

render: function(){

// Handle templating

this.replace($("#photoTemplate").tmpl(this.item));

return this;

remove: function(){

this.$el.remove();

this.release();

}

});

In Spine, controllers are considered the glue for an application, adding and responding

to DOM events, rendering templates and ensuring that views and models are kept in

sync (which makes sense in the context of what we know to be a controller).

What we’re doing in the above example is setting up listeners in the update and

destroy events using render() and remove(). When a photo entry gets updated, we re-

render the view to reflect the changes to the meta-data. Similarly, if the photo gets

deleted from the gallery, we remove it from the view. In case you were wondering about

the tmpl() function in the code snippet: in the render() function, we’re using this to

render a JavaScript template called #photoTemplate which simply returns a HTML

string used to replace the controller’s current element.

What this provides us with is a very lightweight, simple way to manage changes between

the model and the view.

Backbone.js

Later on in this section we’re going to revisit the differences between Backbone and

traditional MVC, but for now let’s focus on controllers.

In Backbone, controller logic is shared between Backbone.View and Backbone.Router.

Earlier releases of Backbone contained something called Backbone.Controller, but it

was renamed to Router to clarify its role.

A Router’s main purpose is to translate URL requests into application states. When a

user browses to the URL www.example.com/photos/42, a Router could be used to

MVC As We Know It | 9

Downloa d f r o m W o w ! e B o o k < w w w.woweb o o k . c o m >

show the photo with that ID, and to define what application behavior should be run

in response to that request. Routers can contain traditional controller responsibilities,

such as binding the events between models and views, or rendering parts of the page.

However, Backbone contributor Tim Branyen has pointed out that it’s possible to get

away without needing Backbone.Router at all for this, so a way to think about it using

the Router paradigm is probably:

var PhotoRouter = Backbone.Router.extend({

routes: { "photos/:id": "route" },

route: function(id) {

var item = photoCollection.get(id);

var view = new PhotoView({ model: item });

something.html( view.render().el );

}

}):

What does MVC give us?

To summarize, the separation of concerns in MVC facilitates modularization of an

application’s functionality and enables:

• Easier overall maintenance. When updates need to be made to the application it

is clear whether the changes are data-centric, meaning changes to models and pos-

sibly controllers, or merely visual, meaning changes to views.

• Decoupling models and views means that it’s straight-forward to write unit tests

for business logic

• Duplication of low-level model and controller code is eliminated across the appli-

cation

• Depending on the size of the application and separation of roles, this modularity

allows developers responsible for core logic and developers working on the user-

interfaces to work simultaneously

Delving deeper

Right now, you likely have a basic understanding of what the MVC pattern provides,

but for the curious, we’ll explore it a little further.

The GoF (Gang of Four) do not refer to MVC as a design pattern, but rather consider

it a “set of classes to build a user interface”. In their view, it’s actually a variation of

three other classical design patterns: the Observer (Pub/Sub), Strategy and Composite

patterns. Depending on how MVC has been implemented in a framework, it may also

use the Factory and Decorator patterns. I’ve covered some of these patterns in my other

free book, JavaScript Design Patterns For Beginners if you would like to read into them

further.

10 | Chapter 1: Introduction

As we’ve discussed, models represent application data, while views handle what the

user is presented on screen. As such, MVC relies on Pub/Sub for some of its core com-

munication (something that surprisingly isn’t covered in many articles about the MVC

pattern). When a model is changed it “publishes” to the rest of the application that it

has been updated. The “subscriber”–generally a Controller–then updates the view ac-

cordingly. The observer-viewer nature of this relationship is what facilitates multiple

views being attached to the same model.

For developers interested in knowing more about the decoupled nature of MVC (once

again, depending on the implementation), one of the goals of the pattern is to help

define one-to-many relationships between a topic and its observers. When a topic

changes, its observers are updated. Views and controllers have a slightly different re-

lationship. Controllers facilitate views to respond to different user input and are an

example of the Strategy pattern.

Summary

Having reviewed the classical MVC pattern, your should now understand how it allows

developers to cleanly separate concerns in an application. You should also now appre-

ciate how JavaScript MVC frameworks may differ in their interpretation of MVC, and

how they share some of the fundamental concepts of the original pattern.

When reviewing a new JavaScript MVC/MV* framework, remember - it can be useful

to step back and consider how it’s opted to approach Models, Views, Controllers or

other alternatives, as this can better help you grok how the framework expects to be

used.

MVP

Model-view-presenter (MVP) is a derivative of the MVC design pattern which focuses

on improving presentation logic. It originated at a company named Taligent in the early

1990s while they were working on a model for a C++ CommonPoint environment.

Whilst both MVC and MVP target the separation of concerns across multiple compo-

nents, there are some fundamental differences between them.

For the purposes of this summary we will focus on the version of MVP most suitable

for web-based architectures.

Models, Views & Presenters

The P in MVP stands for presenter. It’s a component which contains the user-interface

business logic for the view. Unlike MVC, invocations from the view are delegated to

the presenter, which are decoupled from the view and instead talk to it through an

interface. This allows for all kinds of useful things such as being able to mock views in

unit tests.

MVP | 11

剩余154页未读，继续阅读

jimmy7182

粉丝: 0
资源: 1

深入探索Backbone.js应用开发

Developing backbone.js application

Backbone.js应用程序开发

Backbone.js

[Backbone.js] Backbone.js 应用程序开发 (英文版)

深入理解Backbone.js高级语法

使用Backbone.js构建单页应用

探索 RESTful Backbone.js 图书库应用开发

BookLibrary:一个RESTful风格的Backbone.js应用程序，实现了对电子书的简单管理。数据库：Mongodb，服务器：Node.js

RESTful电子书管理应用：BookLibrary与Backbone.js

Backbone.js应用开发指南：从入门到实践

最新资源