HTML and CSS Reference
In-Depth Information
14.3 Domain Model and Storage
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.
Search WWH ::

Custom Search