构建单页应用：Backbone.js与ASP.NET Web API实战

5星 · 超过95%的资源需积分: 9 56 浏览量更新于2024-07-22 1 收藏 7.52MB PDF 举报

"《Pro Single Page Application Development - Using Backbone.js and ASP.NET.2014》是一本由Gil Fink和Ido Flatow合著的专业技术书籍，针对单页应用程序（SPA）开发提供深入指南。该书于2014年发布，旨在帮助开发者理解和构建高效的SPA应用，结合了前端框架Backbone.js和后端技术ASP.NET Web API。本书分为四个主要部分： 1. 道路向单页应用开发：这部分首先介绍单页应用的基本概念，包括其优势、架构原理以及为何它们在现代web设计中的重要性。章节1阐述了单页应用的定义及其与传统网页应用的区别，而章节2则深入讲解JavaScript在SPA中的核心作用，强调了语言的灵活性和性能优化。 2. 构建前端：这一部分着重于使用Backbone.js进行实际开发。章节5为读者提供了入门指南，介绍了Backbone.js的基本结构和用法。随后的章节6通过一步步的实践示例，展示了如何逐步构建一个完整的SPA，包括模型（Model）、视图（View）和控制器（Controller）的设计与协作。 3. 构建后端：在ASP.NET Web API的支持下，本书深入探讨了如何在服务器端实现高效的数据处理和API设计。章节7详细讲解了如何利用ASP.NET创建后端服务，而章节8则聚焦于HTTP概念在Web API中的实现，包括GET、POST、PUT和DELETE等操作。章节9关注前后端之间的通信，确保数据的同步和双向数据流的管理。 4. 高级SPA主题：对于进阶开发者，本书还涵盖了单元测试和性能调优等内容。章节10介绍了JavaScript单元测试的方法和工具，帮助确保代码质量。章节11则讨论了如何通过各种技术和策略提高SPA的性能，如优化网络请求、缓存策略和用户体验优化。《Pro Single Page Application Development》是一本全面且实用的指南，不仅适合初学者了解SPA开发的基础，也对有经验的开发人员在实际项目中应用Backbone.js和ASP.NET Web API提供了深入的参考。书中内容丰富，实例详实，有助于提升开发者的SPA开发能力，并推动项目迈向更高层次的技术实践。"

Chapter 1 ■ IntroduCIng SIngle page applICatIonS

As you can see, the weight on the client side has grown in comparison to the architecture in Figure 1-3, which

showed that traditional web applications used a browser only for HTML rendering. Here you can see that some

business logic is performed on the client side.

Native Applications

Native applications are stand-alone executable applications that need to be installed first. They can run on only

one platform—the platform that they were created for—and this is their strength and also their main weakness.

Native applications are designed to take advantage of the local hardware and operating system. Because there is a

dependency on the hardware and operating system, native application deployments can be very complicated. In each

application version you need to take into consideration operating system versions, driver versions, and even device

architecture (32 bits or 64 bits). That makes the development of native applications harder and their deployment

phase a main issue in the application development process. Figure 1-5 shows a native application architecture

suggestion written by the Microsoft Pattern and Practices team.

User Interface Components

Security

Operational Management

Communication

Presentation Logic Components

Application Facade

Business

Logic

Data Access

Components

Data

Sources

Service

Agents

Business

Workflows

Business

Entities

PRESENTATION

LAYER

CROSS-CUTTING

BUSINESS

LAYER

DATA

LAYER

External

Data

Services

Figure 1-5. Native application architecture

Chapter 1 ■ IntroduCIng SIngle page applICatIonS

In the figure you can see that all the application is created as one piece of software that includes all the logic.

Sometimes you will use external services in native applications but the main processing occurs in the application itself.

As written previously, the dependency on the operating system is a main issue in native application

development. There are a lot of different operating systems like Windows, UNIX, OS X, Android, and more. If you want

to reach clients in all the operating systems you have to make a version of your application for each of them or else you

just narrow the application distribution. That means that you need developers who know how to create an application

for every platform and the time you spend on creating an application can be multiplied by the number of operating

systems that you want to support.

On the other hand, as opposed to traditional web applications, native applications can keep their local state

by using local databases or files. This possibility enables developers to create a rich user experience because

interaction with local resources is faster than using remote resources on remote servers. Moreover, the option to

use local resources enables the application to be available and responsive when there is no Internet connection.

Responsiveness and availability are huge advantages over traditional web applications.

In this section we explained the differences between traditional, modern web applications and native applications.

Now that you have a toolset for comparison between the application types, we can explain what SPAs are.

So What Is an SPA?

As mentioned in the first paragraph of this chapter, an SPA is a full web application that has only one page, which

is used as a shell for all the other application web pages and uses JavaScript, HTML5, and CSS for all front-end

interaction. In SPAs there are no full post back to the server, no full refreshes of a single web page, and no embedded

objects. On the other hand, you use an HTML element in which its content is replaced from one view to the other by

a front-end routing and templating mechanism. Table 1-1 includes a comparison of key application features among

traditional web applications, native applications, and SPAs.

Table 1-1. Traditional, Native, and Single-Page Applications Comparison

Features Traditional Native SPA

Cross-platform functionality √ X √

Client-state management X √ √

No installation required √ X √

As you can see in the table, the SPA is the intersection between traditional web applications and native

applications, and it includes all of their main characteristics. That knowledge can help you when you go to decision

makers to convince them to implement an SPA.

The main difference between an SPA and a traditional application or RIA is the web-page life cycle. Figure 1-6

shows the SPA web-page life cycle.

Chapter 1 ■ IntroduCIng SIngle page applICatIonS

If you compare this to the traditional web application page life cycle shown in Figure 1-2, the main change is the

nature of the requests and responses that follow the initial HTTP request. With an SPA you use Ajax to request data and

you get as a response data in JavaScript Object Notation (JSON) format or prerendered pieces of HTML. Once the data

arrive for the client, the client will partially render the HTML to represent the changes. Also, moving from one page to

another in an SPA occurs on the client side, which is different to what happens in traditional applications and RIAs.

Another change between an SPA and traditional web application is state management. In an SPA, because you

aren’t leaving or refreshing the main web page you can persist your state in the browser memory. Also, if you want to

persist the application state in offline scenarios or when users close the browser, you can use HTML5 storage types to

keep the state. Later on when the user gets back online, you can return him or her to the last state of the application

without involving the server.

The main SPA building blocks include the following:

JavaScript libraries and frameworks: You will use MV* frameworks and many other JavaScript •

libraries in order to build your front end.

Routing: Front-end routing is the way to navigate between views in an SPA. All the views are •

created in the front end inside a main HTML element, and a front-end router manages the

navigation from page to page.

Template engines: A template engine is used on the client side in order to render or rerender •

the parts that are used in the single page.

HTML5: HTML5 is used to create the main SPA web page and to interact with it. You will use a •

lot of new JavaScript APIs for communication, multimedia, storage, and more.

Backend API and Representation State Transfer (REST): The server acts as a web API that the •

app is consuming and doesn’t have a server-side rendering option for web pages.

Ajax: All interactions with the server are asynchronous calls using Ajax. When a response •

arrives from the server, the web page is partially rendered using JavaScript (if needed).

Figure 1-6. SPA web-page life cycle

Chapter 1 ■ IntroduCIng SIngle page applICatIonS

In Chapter 4, “SPA Concepts and Architecture”, those main building blocks will be explained more thoroughly.

While these are the main SPA building blocks there are other essential building blocks that can help develop an SPA

(for example, real-time communication, data management on the client side, etc.). Now that we know what an SPA is,

let’s understand the benefits of creating an SPA.

Why SPA Development?

SPAs integrate the best of two worlds: the native application and the traditional web application. When you develop

an SPA you get the portability and cross-platform functionality of a web application as well as the client-state

management and responsiveness of a native application.

SPAs are web applications and therefore their deployment is seamless to their users. Users don’t need to

install SPAs because they are online as opposed to native applications, which are installed once and later on need

continuous updates for new versions. SPAs can be updated more occasionally by their developers, which creates more

flexibility for the developers.

In SPAs most of the business logic is implemented in the client and the server is used as an API for things like

authentication, validation, or persistency to databases. Because the logic is performed on the client, SPAs are super

responsive and they make users feel like they are using native applications. There is no need to wait for server logic to

occur and for page refreshes because everything is being done on the client.

SPAs are also very responsive in terms of server interaction. All the operations that go to the server are performed

using Ajax and therefore the UI can still receive events and won’t be stuck. Also, if the server operation is very

long, you can notify the user that something is occurring by using notifications or animated images. Again, this is

something the users expect from native applications but get from SPAs.

All of these factors make an SPA the perfect tool for creating next-generation web applications.

Summary

SPAs have been part of web development for a long time. You can create SPAs with plug-ins like Flash, Java, and

Silverlight, but those plug-ins impose a lot of development considerations such as security or user plug-in adoption,

for example. Since 2005, with the combination of Ajax, HTML5, and the mobile web, JavaScript became more

attractive for developers. With benefits like seamless deployment, cross-platform functionality, and more, JavaScript

gained a lot of attention from developers. Moreover, a lot of patterns for building native applications have shifted to

the JavaScript world.

Today, you can’t build a web site or application without investing a lot of your time in writing JavaScript code.

Users expect web sites and applications to run fast and to be fluid. If you don’t give them their desired experiences

they won’t come back to your site or app.

In the next chapter you will learn a lot of good practices for writing JavaScript applications. Understanding these

practices will help you to move forward with the rest of the book.

Chapter 2

JavaScript for SPAs

In Chapter 1 you learned about the history of web development and how we ended up with single page applications

(SPAs). The major part of an SPA is its front end and the main language for writing SPAs is JavaScript. In order to

write maintainable and reusable JavaScript code it is not enough just to learn JavaScript basics. In this chapter and in

Chapter 3 as well, you will delve into techniques and patterns for writing better JavaScript code. In this chapter, you

will get to know how to create and use JavaScript objects, how to create namespaces, and how to mimic encapsulation

in your code. You will also get to know some JavaScript pitfalls and hopefully learn to avoid them.

In Chapter 3, “Modular JavaScript Development”, you will learn about how to create JavaScript modules, what the

Asynchronous Module Definition (AMD) is and how to use the RequireJS library. It is very crucial to understand the

concepts that are described in Chapters 2 and 3 in order to create more successful SPAs.

Note ■ We assume that you know basic JavaScript syntax and that you have some experience with the language.

This chapter tries to be very practical and to show how to write professional JavaScript code.

A Little JavaScript History

JavaScript was created by Brendan Eich around 1995. Brendan developed a language called LiveScript for Netscape

Navigator 2 in order to enable simple processing on the front end. It is said that it took him around 10 days to come

out with the main features of the language. Very close to the Netscape Navigator 2 release, Netscape changed the

LiveScript name to JavaScript and the rest is known. JavaScript adoption was very fast and later on when plug-ins like

Java applets didn’t succeed JavaScript blossomed. Today, JavaScript is the de facto language of the web and some call

it the assembly language of the web.

Around 1997, because of its huge adoption, JavaScript started to be standardized by the ECMA International

standards organization. JavaScript’s first standard edition was released in the same year as the ECMA-262

specification, which is also referred to as ECMAScript. Since ECMA-262 was released the browser vendors are trying

to implement their JavaScript engine according to the specification. The last version of ECMAScript, ECMAScript 5.1,

was released around 2011.

JavaScript was developed as a functional, dynamic, and prototype-based language. It includes good language

features like functions, closures, loosely typed language, dynamic objects, and more. JavaScript also includes a lot of

problematic features like global variables, the with statement, and the continue statement. These features can lead

you into a lot of JavaScript pitfalls so you might want to avoid using them. There is a recommended book by Douglas

Crockford, JavaScript: The Good Parts, that explains all those language features in details.

Now that we have had a little bit of history, our first task is to understand JavaScript functions.

剩余306页未读，继续阅读

sky20079

粉丝: 0
资源: 17

构建单页应用：Backbone.js与ASP.NET Web API实战

Developing Backbone.js Applications

Backbone.js应用程序开发

python train.py --backbone mobilenet --lr 0.007 --workers 1 --epochs 50 --batch-size 8 --gpu-ids 0 --checkname deeplab-mobilenet 是什么意思

deplabv3报错python train.py --backbone mobilenet --lr 0.007 --workers 1 --epochs 50 --batch-size 8 --gpu-ids 0 --checkname deeplab-mobilenet

backbone.conv.0.weight", "backbone.conv.0.bias

python列表中的存储形式为[('backbone.layer.1',tensor[(1,2,3)]),('backbone.layer.3',tensor[(1,2,3)]),('backbone.layer.2',tensor[(1,2,3)]将backbone.删除)]

中文解释backbone.conv.0.weight", "backbone.conv.0.bias

RuntimeError: Error(s) in loading state_dict for YoloBody: Missing key(s) in state_dict: "backbone.conv1.weight", "backbone.bn1.weight", "backbone.bn1.bias", "backbone.bn1.running_mean", "backbone.bn1.running_var",

area 0.0.0.0 abr-summary 1.1.0.0 255.255.0.0 命令案例什么意思

python列表中的存储形式为[('backbone.layer.1',tensor([1,2,3],device='cuda:0')),('backbone.layer.3',tensor([1,2,3],device='cuda:0')),('backbone.layer.2',tensor([1,2,3],device='cuda:0'))]将,device='cuda:0'删除

最新资源