Node.js for .NET Developers (2015)

---

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:

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:

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:

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.

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:

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.)

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.

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.