Node.js：.NET开发者的新选择

需积分: 9 146 浏览量更新于2024-07-20 收藏 3.63MB PDF 举报

“Node.js for .NET Developers” 是一本由 David Gaynes 编著，由 Microsoft Press 出版的书籍，面向熟悉 .NET 和 C# 的开发者，介绍了如何使用 Node.js 进行高效的Web开发。 Node.js 是一个基于JavaScript的开源平台，以其高度可扩展性而闻名，用于构建复杂的网络应用程序。它允许开发人员利用npm（Node Package Manager）模块构建各种类型的网站，从电子商务平台到支持多用户互动的游戏。Node.js 在处理大量、低数据密集型请求或使用WebSocket实现推送技术的应用中表现出色。传统Web应用依赖于客户端发起的无状态请求-响应模式，而Node.js则能帮助开发者构建实时的双向通信应用，使服务器和客户端都能启动通信。本书将帮助 .NET 开发者理解Node.js的工作原理，以及如何将其与HTML、CSS和JavaScript等标准Web栈结合使用。通过学习，开发者可以掌握如何利用npm添加样式库，构建自己的模块集合，以适应不同类型的Web项目需求。 Node.js 的优势在于其非阻塞I/O模型和事件驱动的架构，这使得它在处理高并发场景时具有极高的效率。此外，对于需要实时交互的应用，如聊天室、在线协作工具或游戏服务器，Node.js 提供了理想的解决方案。书中的内容可能包括但不限于以下几个方面： 1. **Node.js基础**：介绍Node.js的核心概念，如V8引擎、事件循环和单线程模型。 2. **npm模块管理**：详细讲解如何使用npm安装、管理和共享代码模块。 3. **Web服务器创建**：教授如何用Node.js构建HTTP服务器，处理请求和响应。 4. **实时通信**：深入探讨WebSocket协议，展示如何实现实时双向通信。 5. **异步编程**：讲解如何有效地处理异步操作，避免回调地狱。 6. **错误处理**：介绍Node.js中的错误处理机制，确保程序的健壮性。 7. **性能优化**：讨论如何优化Node.js应用，提高其运行效率。 8. **集成.NET与Node.js**：可能会涉及如何在现有.NET项目中使用Node.js服务，或者反之。这本书还可能涵盖了如何从.NET和C#开发的角度去理解和迁移至Node.js平台，帮助开发者充分利用两者之间的相似性和差异性，提升跨平台开发能力。 “Node.js for .NET Developers” 是一本面向有.NET背景的开发者，旨在让他们快速掌握Node.js并应用于实际项目的实用指南。书中丰富的示例和实践建议，将有助于读者在Web开发领域中拓展新的技能和视角。

Put these together using the plus (+) sign like this:

Click here to view code image

var iResult = iNumber + sNumber;

You will get no type mismatch errors, and you will not get addition even if you hoped for it. You will get concatenation:

020

Now suppose you are used to programming in Microsoft Visual Basic.NET and you accidentally concatenate using the

ampersand (&) symbol in one place, like this:

Click here to view code image

var iResult = iNumber + sNumber & myNewNumber;

Now you get this as output:

What’s happening? In JavaScript, the ampersand is a bitwise operator that returns true or false. In this case, the output 0

means false and has exactly nothing to do with your variable values in code. Additionally, JavaScript is not strict with

declarations and would actually let you try to run exactly the code just shown as is, not warning you that myNewNumber didn’t

exist until runtime when the code suddenly and unexpectedly failed.

Note

The newest browsers will now recognize the use strict statement. If you place this globally in your .js file, it will at

least prevent the last instance just shown.

Admittedly, this is just sloppy coder coding, but it illustrates how the general idea of a non-typed language can lead to a

whole mess of problems if you aren’t extremely careful. I have always been a big advocate for a limited “Hungarian notation”

when coding, meaning you declare an int with the name iValue and a string with the name sValue so that when you have 3,000

lines of code, you know what’s what when debugging without having to dig back through your code and find the type

declaration, wherever it might be.

JavaScript is a keep-it-neat idea on steroids, so it won’t help you with types at all. If you don’t tell yourself, by variable

name, what this value or object is that you have running around in your code, you are making a heap of trouble for yourself.

Keep in mind that this problem soon cascades into your functions, as illustrated by this part of line 2 of the earlier code:

function (req, res)

This is a function declaration in JavaScript that takes two passed in arguments. As you can see, they have no types at all. In

this case, JavaScript has to look at the rest of the call in which this function is embedded (which I will discuss in more detail

shortly) and match it to an expected signature in the npm package. The npm package is just a JavaScript file library that, no

doubt, contains some JavaScript object, the type of which is expected in this function as argument one or two. Thus, if you

make a reference to some property of the object, such as on line 4 shown here, somewhere up the tree it fits together:

res.end(...);

This isn’t exactly intuitive if you come from the land of strong typing! You simply have to know the right properties to use

and how to use them. You’ll get a lot of very unintuitive errors about things being “undefined” when you don’t.

I didn’t mean to jump around the code shown earlier, but you can see everywhere how important this idea of non-strong-

typing really is within JavaScript. Danger! Danger everywhere, Will Robinson! So be advised.

Now that I’ve covered that, let’s get back into the code shown earlier and the line where you left off:

var http = require('http');

This is the standard way of including a Node.js module in your code. Think of it as your import or includes statement. If you

don’t have the module installed that you try to reference in this line, your code will throw an error telling you it has no clue

what you mean.

Here you didn’t actually install an “http” module, so the need to do this process right here is just a quirk of this particular

Node.js base library. And, as I said, you won’t be using it anyway. But the require function call is the same in almost all cases,

and it returns some object that is useful in some important way. Again, you are the one who needs to know what the object and

its properties will be when it returns to you.

In this case, http has just one important thing that it can do, and that is create a web server using the http.createServer();

function call. That function call contains another boatload of JavaScript information and, equally as important, information

about how Node.js expects you to write it for everything to work properly. The line of code without the meat in the middle is

http.createServer(function (req, res) {});.

Yes, this really is a function that takes a function as an argument. In JavaScript, even a function is an object. The closest

comparison in .NET-land would be a delegate, which is an object wrapper around a function.

Note

I actually said that backwards. The fact is every object in JavaScript is declared as a function. I’ll get to this, too, very

shortly. I do realize that if all you have done with JavaScript up until this point is hide and show some divs with JQuery,

this is fairly mind-expanding stuff. I’ll keep it as simple as I can and let you run with the rest when you’re ready.

Let’s get back to our one line of wondercode:

Click here to view code image

http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/plain'});

res.end('Hello World\n');

}).listen(1234, '127.0.0.1');

The special thing about JavaScript and passing functions to functions (such as function A as an argument to function B) is that

function B doesn’t actually use that function per se or anything that it does. Instead, it wires that function as a callback.

A callback function is basically the same as a callback from your local phone company. If you call the phone company (if

it’s a modern phone company, that is) when customer service is busy, you will get an option to leave your number and have the

company return the call or “call you back” when they are ready to service you. In other words, they’ll call you when they are

done doing whatever else they were doing before they could get to you. The callback function A receives the result of function

B and then can act upon that result.

This concept, using callback functions in every action you take in JavaScript, is the essence of Node.js programming. It

creates what is known as the asynchronous model of code.

Something is synchronous if it always runs in order, A and then B and then C. But if B is a callback function, meaning it

begins to run only when function A has some final result for it to start working on, then C could run after A finishes but before

B is done running, making the code asynchronous:

Click here to view code image

obj.myFunctionA(functionB (x) {});

obj.myFunctionC();

Just passing an argument that JavaScript thinks is an object like any other (!) doesn’t stop code from running. So the

JavaScript processor (which could be the subject of a whole book on its own if it isn’t already) thinks that function A is done

when whatever is in its brackets is done running. It couldn’t care less about the fact that function B hasn’t yet finished doing

what it needs to do before function C goes ahead and leaves the starting gate.

Despite whatever complications this idea introduces to your code and data logic, it contains a tremendous amount of power

and potential. At its most basic level, if function A is a web request and function C is also a web request, then C does not have

to wait for the results of A (meaning B) to finish processing or rendering before beginning to run. As long as B, which is now

running in its own little universe, is not touching any resources common to C, by following this model cleverly enough you can

conceivably craft a way to spin a huge number of concurrently running universes, all processing their own requests in their own

space. They are completely independent of any other resource and serve up webpages at the absolute optimum speed for each

one.

All of this helps explain some of the anecdotal evidence I referred to at the beginning of the book, and it explains why we

have Node.js in the first place. The widespread use of the callback model creates asynchronous processing of web requests,

and it can have a huge positive impact on performance.

That’s really all it is. After that, you do everything by hand to fit the model. Doing this, of course, would be practically

impossible on a day-to-day commercial basis when compared dollar-for-dollar against almost anything with prebuilt toolkits

containing everything from controls to styling to database connections and more. Hence, you see an explosion in the number of

npm packages to bring those development times more in line with other approaches and, thus, the current state of Node.js

development.

Once you accept all the concepts I’ve touched on in the last few pages, you can start to dissect what’s happening:

Click here to view code image

http.createServer(

function (req, res)

{

res.writeHead(200, {'Content-Type': 'text/plain'});

res.end('Hello World\n');

})

The function createServer is not taking any arguments other than a callback function. So somewhere in the Node.js backbone

lives this HTTP object. It does what it does, expecting you to provide a function with exactly this signature, which it will then

call when it is done. That callback function is expecting to pass two arguments generated by the backbone. As the names imply,

these arguments will be objects you are familiar with in the world of HTTP: a request object and a response object.

Note

As I talked about earlier, in the land of JavaScript there is no way to know what objects are without cluing yourself in

by using the name and then referring to your own code or whatever documentation you can get your hands on. These are

some of the reasons this book is intended for people who have had at least some experience doing real-world web

development. For a novice programmer, Node.js would be totally baffling without it.

You can see that the response object contains properties and functions you can recognize: a writeHead function and an end

function that has at least one overload version that accepts some plain text to write to the response as it ends itself. In this case,

we are writing Hello World.

One major thing to note: as written, this server will return Hello World for every web request it receives. That’s not very

practical. How to recognize routes and then do the routing is covered later. You will use the features contained in the Express

npm package as the backbone for that functionality, not the Node.js core itself. But you can dig down into the HTTP object and

this callback function, and you can do it here if you choose to.

Finally, you need to turn it on. That’s what this line does:

.listen(1234, '127.0.0.1');

Whatever object is returned from the createServer function you called must have a listen function as one of its properties

that activates the underlying server code. And that function needs an IP address and a port on which to listen for requests. The

code could be written as follows for clarity:

Click here to view code image

var server = http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/plain'});

res.end('Hello World\n');});

server.listen(1234, '127.0.0.1');

However, the infamous JavaScript processor apparently prefers the “chained” version for reasons of its own. So use it when

you can.

Note

Optimized JavaScript can lead to some of the most unreadable code on the planet. It is simply a tradeoff you are

required to make for the sake of performance if that level of performance really does matter to you—and it might,

depending on the circumstances.

How’s that for one line of code? Welcome to the heart and soul of JavaScript Land—its capital city, Node.js.

The infrastructure supporting the capital city, referred to no less than four times in the one line of code just shown, is Object-

Oriented JavaScript (OOJS). Some objects in the preceding code are created; others are referenced by inference, and still

others are referenced directly using properties or methods. Anything as important as the underlying foundation for a kingdom

better be solidly designed, so without getting overly verbose on the subject let’s spend a few minutes talking about some best

practices for OOJS:

Object-Oriented JavaScript

As I mentioned earlier, every object in JavaScript is declared as a function:

function Person(){}

In turn, as you saw from the entire callback structure, every function also acts as an object. Some people in JavaScript Land

use Function to refer to an object (a collection of related code) and function to refer to a method (code that performs a single

specific action). I’ll stick with the standard references, all similarities in syntax aside.

Let’s begin with an object you will actually build on and use later as you go along. You’re going to design a simple Sports

Survey Web Application that will generate a few questions to a UI and allow users to interact and generate responses to those

questions. There are a couple of what I refer to as classes (objects) that you will need to offer—for example, a few choices

between players on a question. Those objects, to start with, include a Player object and a Question object.

A Player is a Person, so let’s start with the line of code shown earlier and something common to all people and players:

function Person(){

this.lastName = "";

this.firstName = "";

}

If you are wondering when you declared that property or the fields/properties called lastName and firstName, the answer is

“You just did.” The magic keyword this has created the reference to those properties on the fly. Yes, this has innumerable

potential hazards. No, this is not unique to Node.js. So let’s just plow on as if we didn’t have any issues at all. Life in

JavaScript Land is like this every day. You get used to it by being extremely careful in your code practices.

So next you narrow down the kind of person you need, and that is a player. First and foremost, a player is a person. When

you create the Player object, first you tell it that it is a Person by using the prototype property like this:

Click here to view code image

function Player () {

this.prototype = Person;

this.sport = "Football";

this.displayName = function(){

return(this.lastName + ',' + this.firstName);

}

As you see, to make a property into a method, you just declare it as a function. Now any Player object you declare will also

have all the properties of a Person, and this code will work to pop up a message box with the concatenated name of the player:

var oPlayer = new Player();

oPlayer.firstName = "Walter";

oPlayer.lastName = "Payton";

alert(oPlayer.displayName());

In this case, it seems as if you should actually call this object FootballPlayer. As you can see from the code, the value

Football is hard-coded into the sport property, thus defining all Players who are instantiated using the Player object function

call (constructor) as FootballPlayers. Play with this pattern as you like using prototypes to help encapsulate your code and

eliminate redundancy where you can.

You can override a function in the prototype from the child class this way:

Click here to view code image

this.displayName = function(){

this.lastName + ',' + this.firstName;

}

This is just like any other property. You simply set the value to something new—in this case, a new function. So you could

have made the code look like this for a BaseballPlayer object:

Click here to view code image

var oPlayer = new Player();

oPlayer.firstName = "Babe";

oPlayer.lastName = "Ruth";

oPlayer.position = "Pitcher"; // yes he started as a pitcher!

this.displayName = function(){

this.lastName + ',' + this.firstName + ":" + this.position;

}

alert(oPlayer.displayName());

It produces similar output as before, only from slightly neater code.

Again, you can add new properties and functions willy-nilly (either intentionally or by accident) to your child class. You are

not required to implement anything at any level of the so-called object tree as with genuine inheritance for .NET objects and

interfaces. These kinds of OOJS practices are recommended only for code consistency, maintainability, and patterning for your

benefit. That means if you prefer to call your Player function showAllOfMe, feel free to go ahead. JavaScript will not care at

all.

Click here to view code image

var oPlayer = new Player();

oPlayer.firstName = "Walter";

oPlayer.lastName = "Payton";

this.showAllOfMe = function(){

this.lastName + ',' + this.firstName + ":" + this.sport;

}

alert(oPlayer.showAllOfMe());

However, if you’re going to override every function of your prototype base class, there is little point in having a

child/prototype set up because all it does is add convenience.

Now you have the Player object that will help you assemble answers to your sports survey questions. You will need a list of

questions, thus the next object you need is a Question object:

Click here to view code image

function Question(oQuestion, oAllAnswers, oCorrectAnswer) {

this.questionText = oQuestion;

this.answersList = oAllAnswers;

this.correctAnswer = oCorrectAnswer;

}

As you can see, this function is expecting a bit more to make a Question object than the Player function did to make a Player

object. This object clearly needs some outside data to assemble properly. Again, notice the weak typing. For example, the

following is obviously going to be some kind of list or array. That’s obvious only because its name implies that it must be such

a list to work as you logically need it to:

this.answers = oAllAnswers;

The following line is equally obviously only a single value holding, most likely, just text. (There is only one possible bit of

text content for any individual question.)

Click here to view code image

this.questionText = oQuestion;

And this next line also clearly will hold a single value of whatever kind you choose that works best for you. However, just

based on this, you don’t know if it’s a numeric or GUID-style ID that matches some AnswerID you have somewhere or if it’s a

text value that matches the actual content of a displayed answer.

Click here to view code image

this.correctAnswer = oCorrectAnswer;

Try to develop good habits when writing code so that you can tell what is going on in your code at all times. It will make

your life much easier. I’ll get back to fleshing out our “classes” later as you develop the code.

As I said earlier, my intention here is only to scratch the surface of OOJS to introduce you to its best practices for

consistency and maintainability. The details of the various designs for prototyping and deriving objects of all kinds can be

explored in much greater depth from a wide range of resources if you have the need and interest. For your purposes at this

point, the basics of OOJS and how it is used in existing packages are enough to wrap your head around. These basics also

cover how you should use OOJS to pass and manage information and behavior in your Node.js project.

You have seen the Node.js core create a server from a single, albeit slightly complex, function call. You poked around into

OOJS to get a feeling for good patterns and functionality within the JavaScript world. And you combined those to analyze that

single line of JavaScript code to help you better understand what that code actually does. In addition, examining that code

showed you how best to use Node.js to follow the most effective patterns when building a site.

I’m sure you’re more than ready to start creating something that works—an actual website generated from Node.js. You have

all the background you need to do so effectively. So let’s begin right now.

剩余187页未读，继续阅读

mrgamble

粉丝: 0
资源: 7

Node.js：.NET开发者的新选择

Learning Node.js for .NET Developers azw3

Learning.Node.js.for..NET.Developers.epub

Learning Node.js for .NET Developers(PACKT,2016)

eclipse配置node.js

webpack < 5 used to include polyfills for node.js core modules by default

node.js 豆包api

node.js status

webpack ＜ 5 used to include polyfills for node.js core modules by default

nodewebassembly

https://cdn.jsdelivr.net/npm/vue 过期

最新资源