构建现代应用：Backbone.js与Node、Express技术探索

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

《Developing Backbone.js Applications》是一本由Addy Osmani编著的教程，旨在帮助读者使用现代技术栈（如Node.js和Express）开发高效的应用程序，并解决Backbone.js和jQuery Mobile中的路由问题。该书特别关注于Backbone.js框架的深入理解，包括Model-View-Controller (MVC) 和 Model-View-Presenter (MVP) 设计模式。在本书的开篇，作者首先介绍了MVC模式的基本概念，从Smalltalk-80 MVC模型出发，解释了它如何演变成为我们今天所熟知的设计模式。这部分内容对于理解Backbone.js的核心理念至关重要，因为Backbone.js正是基于MVC架构构建的。书中着重讲解了Backbone.js的组件，如模型（Models）、视图（Views）和控制器（Controllers）。模型用于处理数据，视图负责展示数据，而控制器则负责协调这两者之间的交互。通过对比Spine.js和Backbone.js在控制器实现上的不同，读者可以更好地理解两种框架的异同。接下来，作者深入探讨了MVC模式带来的益处，以及为什么选择使用Backbone.js。此外，还涉及了MVP模式，让读者了解其在某些场景下的优势和与MVC模式的区别。书中还提供了快速参考（Fast facts），方便读者在实际开发中查阅关键信息。在技术细节部分，书里涵盖了Backbone.js的核心组件路由器（Routers）的使用，特别是Backbone.history模块，以及命名空间（Namespacing）的概念和其实现技巧。作者强调了自动化Backbone.js项目结构生成工具的价值，以便提高开发效率。《Developing Backbone.js Applications》是一本全面且实用的教程，不仅适合初学者学习Backbone.js基础，也适合有一定经验的开发者深化对框架的理解，以及在实际项目中优化应用架构。通过阅读这本书，读者将能够掌握如何利用Backbone.js构建现代Web应用程序，并充分利用其优点来简化开发流程。

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页未读，继续阅读

luxas

粉丝: 0
资源: 23

构建现代应用：Backbone.js与Node、Express技术探索

Developing Backbone.js Applications

JavaScript快捷键库keyboard.backbone.js.zip

Backbone.js.Cookbook-Backbone.js开发秘笈.pdf

Developing Backbone.js Applications:适合初学者和高级用户的一本关于 Backbone.js 的书-开源

template.phonegap.gulp.browserify.react.backbone:PhoneGap 应用程序的样板模板

Developing backbone.js application

最新资源