（M）VCフレームワーク機関車

数日間、いくつかのデモタスクを解決するためにNode.jsフレームワークを選択しています。 4つのフレームワーク（ Locomotive 、 Express 、 Geddy 、 Sails ）と、Locomotiveから始めることにした記事のサイクルを調べました。



Locomotiveは私の友人の推薦に気付きました。「聞いてください。Expressの上にMVCを実装する興味深い新しいフレームワークがあります。」-これに興味があり、その後「実験的」のリストにLocomotiveが追加されました。

機関車のアーキテクチャと一般的な概念

Locomotiveは、「MVCとRESTの原則を厳密に遵守しており、設計されたアプリケーションでうまく書く傾向があります」と表現しています。最後まで。 私の意見では、「モデル」部分は少なくとも何らかの形で実装する必要があるため、このステートメントは開発されましたが、Locomotiveのドキュメントでは、著者は記事「ポリグロットの永続性」を参照し、自分でデータベースとORMを選択して自分でねじ込むことができると述べましたフレームワークに、著者のこのアプローチは、計算がMVC（Model2）を完全に実装するこのフレームワークを選択するときであったため、少しイライラしました。 そこで実装されているものに戻りましょう。

Expressにより「View」が実装され、 Jade 、 Ejsなどのテンプレートと統合されます 。

「コントローラー」は、原則として完全に実装されており、ベースコントローラークラスがあり、クライアントからのリクエストを実際に処理してレスポンスを返すことができます。 各メソッド内にはコントローラーアクションがあり、各アクション内では現在のコンテキストからルーティングパラメーターを直接取得できます。

var SearchController = new Controller(); SearchController.find = function() { this.query = this.param('query'); // execute search query... } module.exports = SearchController;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「アクションアシスタント」も利用でき、特定のアクションを実行する直前または実行後にアクセスできます（Locomotiveでは「 フィルター 」と呼ばれます）。

 PhotosController.before('show', function(next) { var self = this; if (this.param('id')) { next(); } else { return next(“Error”); } }); PhotosController.show = function() { this.render(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、「show」アクションの直前に実行される「アクションアシスタント」を挿入します。これにより、識別子パラメーターを確認し、リクエストを続行するか終了するかを決定できるレイヤーが追加されます。 また、コントローラーのアクションの前に実行される「アクションアシスタント」を追加できます。

 PhotosController.before('*', function(next) { //       PhotosController });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、「アクションアシスタント」に加えて、Locomotiveは「コンテンツネゴシエーション」メカニズム（http://en.wikipedia.org/wiki/Content_negotiation）をサポートしています。つまり、アクション内で、クライアントが要求する形式に応じてプレゼンテーションを表示するいくつかの方法を登録できます、簡単に次のようになります。

 PhotosController.index = function() { this.respond({ 'xml': { template: 'feed' }, 'html': { template: 'index' } }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、PhotosControllerは、ユーザーがヘッダーで要求した形式に応じて、2つの形式のいずれかでビューを返します。 このAcceptヘッダー値を使用すると、アクションは登録済みのインデックステンプレートを自動的に返します。



Accept: text/html;







実際、これらの機能の周辺には大きな「グッズ」はたくさんありませんが、詳細には触れません。ドキュメントを書き直す理由はありません。



そして、Locomotiveで私が最後に興味を持ったのは、どのようにExpress ルーティングを拡張したかです。 彼らは「プレースホルダー」でルートを作成できるようにするmatch（）を実装しました：

  this.match('songs/:title', { controller: 'songs', action: 'show' });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の意見では、彼らは興味深い「砂糖」を追加し、ルートだけでなく、RESTを介して操作されるリソース全体を記録しました。 つまり、次のような行です。

  this.resources('photos');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のようなルートを利用できるようにします。

方法：	ルート：	アクションの促進：
ゲット	/写真	インデックス
ゲット	/写真/新しい	新しい
投稿	/写真	作成する
ゲット	/写真/：id	見せる
ゲット	/写真/：id /編集	編集する
置く	/写真/：id	更新する
削除	/写真/：id	破壊する

また、PhotoControllerによってこれらのルートの動作を、「アクションへのマッピング」列の対応するアクションとともに記述することができます。 機能自体はシンプルですが、時間を節約するのに役立つ場合があります。 これらの「トリック」には多くのカスタマイズがありますので、「AAAAAAを表示して編集するだけならどうするか」と考える必要はありません。開発者もこれを処理しました 。

インストールと構成の容易さをテストする

「私はそれを行い、Locomotive + Socket.ioをインストールして構成し、必要なすべてのデモを作成しました」と言いたいのですが、多くの問題がありました。 機関車は、Expressと同じくらい簡単にインストールできます。

 npm install locomotive -g
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、プロジェクトを作成します。

 lcm create project
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして実行：

 cd project && lcm server
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これまでのところ、 http：// localhost：3000でブラウザを開くと、Locomotiveは元気に挨拶をします。

しかし、私の目標は、Locomotiveを構成して、通常はWeb Socket要求を処理し、ファイルをアップロードできるようにすることでした。

LocomotiveはExpressの上に構築されているため、ファイルのダウンロードに問題はありません。Expressで動作するのと同じように、Locomotiveでも動作します。

しかし、Web Socketsを使用すると、少し不快な状況であることがわかりました。 何らかの理由で、Locomotive開発者は、Express（アプリ）オブジェクトの作成をフレームワークの一部として閉じて、Express.ioなどでExpressをラップする可能性を遮断する必要があると考えました（もちろん、コードに愚かなパッチを適用できますが、これらは私たちの方法ではありません）。 その後、Express.ioはLocomotiveが書かれている上にExpressに完全に載っているので、Locomotiveに最適でしたが、Express.ioを使用するという考えを捨てました。 次に、Socket.ioに直接接続することにしましたが、ここでもがっかりしました。 ここでは、人々 が「大騒ぎ」なしではこの問題を解決できないリンクの例を示します。Locomotive開発者はGithubで「プルリクエストをマージする」ことを急いでいません。 はい、そしてどういうわけか開発キャンペーンは、Githubでのコミットの履歴から判断して、このフレームワークをまったく超えていません。

結論として

結論として、原則として、Locomotiveアドインは悪くありませんが、私の意見では、それは絶対に拡張可能ではありません。つまり、フレームワーク自体の多くを詰め込まなければならないので、それでさらに拡張可能な何かをする危険はありません。

しかし、「ランディングページ」や「名刺」を作成するなどのタスクの場合は、Locomotiveが非常に適しています。



使用された文献：



http://locomotivejs.org/guide