【NodeJS】先端ルートの運転機構を分析する

一、ルータ
ルータコンポーネントは、フロントエンドがルーティングの変化を監視し、応答するためのツールです.これにより、より少ないバックエンドサーバに依存してURIを解析し、対応するコンテンツを返すことができる.現在も多くのサイトでこの方法が使われていますが、この方法は応用を構築する際にいくつかの欠点があります.
最も主要な問題は、ユーザーインターフェースが移植可能であることを望むことである.つまりバックエンドはどんな技術で開発されていても、先端アプリケーションは正常に配置され、作業されています.私達はバックエンドのURIのためにページを組み立てるのではないので、バックエンドにルートを解析させる必要がないです.
二、ルートの変化にどう応えるか
通常は二つの方法があります.最初の方法は、ルーティングを宣言し、調整関数を結合することである.もちろんルートが多い時はこの方法はあまり理想的ではないです.第二の方法は、ルーティングがアクティブになるとイベントをトリガすることである.これは、イベントがルートと直接的に結合されることなく、いくつかのコンポーネントによってこれらのイベントを傍受することを意味する.この方法はルートが多いときに非常に有用である.ルータがこれらのコンポーネントに対して何も知らないため、ルートだけを知っています.
三、ルートを実現する方法
JavaScriptでルートを実現するには二つの方法があります.第一に、hashベースのURIを利用して、これらのURIは菗文字で始まるので、この方法はより一般的です.もう一つの一般的ではない方法は、ブラウザのhistory APIを利用して、より多くの伝統的なURIを生成することであり、Webアプリケーションでよく見られるURIである.この技術はもっと複雑で、最近やっと十分なブラウザサポートを得てこの方法を実現します.
四、依存注入でばらばらにルートモジュールを追加する
私達のサーバーはルートの存在を知って有効に利用するべきです.もちろん、この依存項はハードコードによってサーバに結び付けられますが、他の言語のプログラミング経験から、これは非常につらいことになると教えられています.したがって、私たちは注入に依存する方法を使って、より緩やかにルートモジュールを追加します.

// file server.js

var http = require("http");
var url = require("url");

function start(route) {
    http.createServer(function (request, response) {
        var pathname = url.parse(request.url).pathname;
        console.log("Request for " + pathname + " received.");

        route(pathname);

        response.writeHead(200, {"Content-Type": "text/plain"});
        response.write("Hello World");
        response.end();
    }).listen(8888);
    console.log("Server has started.");
}

exports.start = start;

// file router.js

function route(pathname) {
    console.log("About to route a request for " + pathname);
}

exports.route = route;

// file index.js

var server = require("./server");
var router = require("./router");

server.start(router.route);         //             

/*          ：     A   C  ，  B    ，B       XML            ：“ A     ，    C  ”。
           ，    A  ，          C   。     C A   ，     C   A    ，    ，A C      ，    B，         。 */

注:以上のserver.js、router.js、index.jsの3つのファイルは同じレベルのディレクトリにあります.
五、構造の面でどうやってルートを設計しますか?
アーキテクチャの面でルーティングについて考慮する必要があるのは、グローバル単一ルートを設計するか、それともモジュールごとにルーティングまたは他のコンポーネントを設計したいということである.
グローバル単一ルーティングの問題は、機能とルーティングが絶えず増加すると、アプリケーションはますます大きくなり、ますます拡張しにくくなります.その利点は、すべてのルーティングが同じ場所にあると宣言し、単一のルーティングはまた、すべてのコンポーネントが傍受できるイベントをトリガすることができる.
第二の態様では、各モジュールはルータの実例を持っている.例えば、応用の中に5つのコンポーネントがあれば、それぞれのコンポーネントは自分のルータを持っています.このような利点は、モジュールごとに自己が含まれており、利用者は対応するルートを探す必要がない.さらに、このスキームでは、ルート定義と応答関数の間の結合がより緊密であり、コードがより簡潔であることを意味する.このスキームの欠点は、ルーティングステートメントが各モジュールに分散されており、集中的に保存されていないことである.