HTML and CSS Reference
In-Depth Information
The domain model of the chat application will consist of a single
chatRoom
object
for the duration of our exercise.
chatRoom
will simply store messages in memory,
but we will design it following Node's I/O conventions.
14.3.1 Creating a Chat Room
As with the controller, we will rely on
Object.create
to create new objects
inheriting from
chatRoom
. However, until proved otherwise,
chatRoom
does
not need an initializer, so we can simply create objects with
Object.create
directly. Should we decide to add an initializer at a later point, we must update the
places that create chat room objects in the tests, which should be a good motivator
to keep from duplicating the call.
14.3.2 I/O in Node
Because the
chatRoom
interface will take the role as the storage backend, we
classify it as an I/O interface. This means it should follow Node's carefully thought
out conventions for asynchronous I/O, even if it's just an in-memory store for now.
Doing so allows us to very easily refactor to use a persistence mechanism, such as a
database or web service, at a later point.
In Node, asynchronous interfaces accept an optional callback as their last ar-
gument. The first argument passed to the callback is always either
null
or an error
object. This removes the need for a dedicated “errback” function. Listing 14.28
shows an example using the file system module.
Listing 14.28
Callback and errback convention in Node
var fs = require("fs");
fs.rename("./tetx.txt", "./text.txt", function (err) {
if (err) {
throw err;
}
// Renamed successfully, carry on
});
This convention is used for all low-level system interfaces, and it will be our
starting point as well.
