19

JavaScript コードはどのように構成されていますか? MVC などのパターンに従っていますか?

私はしばらくサイド プロジェクトに取り組んできましたが、さらに進めば進むほど、私の Web ページはフル機能のアプリケーションに変わりました。今のところ、私はjQueryに固執していますが、ページのロジックは、何らかの組織、またはあえて言うなら「アーキテクチャ」が必要なところまで成長しています。私の最初のアプローチは「MVC風」です：

  • 「モデル」は、ヘルパーで拡張される JSON ツリーです
  • ビューは DOM とそれを微調整するクラスです
  • コントローラーは、イベント処理を接続し、ビューまたはモデル操作を開始するオブジェクトです

しかし、他の人々がどのようにより実質的な JavaScript アプリケーションを作成したかについては、非常に興味があります。私はGWTやその他のサーバー指向のアプローチには興味がありません...「javaScript + <generic web service-y thingy here>」のアプローチだけです

注: 前に、javaScript は「実際には OO ではなく、実際には機能しない」と述べました。これは、みんなの気を散らしたと思います。このように言いましょう。javaScript は多くの点でユニークであり、私は厳密に型指定されたバックグラウンドを持っているため、私が知っているパラダイムを強制したくありませんが、非常に異なる言語で開発されました。

4

7 に答える 7

7

..しかし、Javascript にはOO である多くの側面があります。

このことを考慮：

var Vehicle = jQuery.Class.create({ 
   init: function(name) { this.name = name; } 
});

var Car = Vehicle.extend({ 
   fillGas: function(){ 
      this.gas = 100; 
   } 
});

私はこの手法を使用して、独自の状態を持つページ レベルの JavaScript クラスを作成しました。

これは、実行する独自のスクリプトを持つコンポーネント/サーバー コントロールがあり、同じページに複数のインスタンスがある可能性がある場合にも特に役立ちます。これにより、状態が分離されます。

于 2008-08-28T15:29:51.863 に答える
4

JavaScriptMVC は、大規模な JS アプリケーションを編成および開発するための優れた選択肢です。

アーキテクチャ設計は非常によく考えられています。JavaScript でできることは 4 つあります。

  1. イベントに応答する
  2. データのリクエスト / サービスの操作 (Ajax)
  3. ドメイン固有の情報を ajax 応答に追加します。
  4. DOM を更新する

JMVC は、これらをモデル、ビュー、コントローラーのパターンに分割します。

まず、おそらく最も重要な利点は、コントローラーです。コントローラーはイベント委任を使用するため、イベントを添付する代わりに、ページのルールを作成するだけです。また、コントローラーの名前を使用して、コントローラーが動作する範囲を制限します。これにより、コードが決定論的になります。つまり、「#todos」要素でイベントが発生した場合、todos コントローラーが必要であることがわかります。

$.Controller.extend('TodosController',{
   'click' : function(el, ev){ ... },
   '.delete mouseover': function(el, ev){ ...}
   '.drag draginit' : function(el, ev, drag){ ...}
})

次はモデルです。JMVC は強力なクラスと基本モデルを提供します。これにより、Ajax 機能をすばやく整理し (#2)、ドメイン固有の機能でデータをラップできます (#3)。完了すると、次のようなコントローラーのモデルを使用できます。

Todo.findAll({after: new Date()}, myCallbackFunction);

最後に、ToDo が戻ってきたら、それらを表示する必要があります (#4)。ここで、JMVC のビューを使用します。 

'.show click' : function(el, ev){ 
   Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
   $('#todos').html( this.view(todos));
}

「views/todos/list.ejs」内

<% for(var i =0; i < this.length; i++){ %>
   <label><%= this[i].description %></label>
<%}%>

JMVC は、アーキテクチャ以外にも多くの機能を提供します。開発サイクルのあらゆる部分で、次のことを支援します。

  • コードジェネレーター
  • ブラウザ、Selenium、Rhino の統合テスト
  • ドキュメンテーション
  • スクリプト圧縮
  • エラー報告
于 2009-08-22T20:37:05.160 に答える
3

MochiKit は素晴らしいです。js ライブラリに関する限り、いわば私の最初の愛でした。しかし、MochiKit には非常に表現力豊かな構文がありますが、Prototype/Scriptaculous や jQuery ほど快適に感じることはできませんでした。

Python を知っているか好きなら、MochiKit は良いツールだと思います。

于 2008-08-29T19:58:55.987 に答える
2

ご回答ありがとうございました。しばらくして、これまでに学んだことを投稿したいと思います。

これまでのところ、 Extのようなものと、 JQuery UI、Scriptaculous、MochiKitなどの他の ものを使用したアプローチには非常に大きな違いがあります。

Extを使用すると、HTMLは単一のプレースホルダーになります-UIはここにあります。それ以降、すべてがJavaScriptで記述されます。DOMの相互作用は、別の（おそらくより強力な）APIレイヤーの下で最小限に抑えられます。

他のキットでは、HTMLデザインを少し行うことから始めて、DOMを洗練された効果で直接拡張するか、ここに入力されたフォームを置き換えて、そこに追加します。

イベント処理などを処理する必要があるため、大きな違いが生じ始めます。モジュールは相互に「対話」する必要があるため、DOMから離れて、断片的に抽象化する必要があります。

これらのライブラリの多くには、いくつかの興味深いモジュール化手法も含まれていることに注意してください。非常に明確な説明がExtWebサイトに掲載されており、モジュールを使用してコードを「保護」するための優れた方法が含まれています。

私が完全に評価した新しいプレーヤーはSproutcoreです。DOMが隠されているアプローチでは、Extのように見えます。ほとんどの場合、プロジェクトのAPIを処理する必要があります。

于 2008-09-15T13:17:22.547 に答える
2

Tristan、JavaScriptをMVCアプリケーションとしてアーキテクチャ化しようとすると、モデルという1つの領域で不足する傾向があることがわかります。データはアプリケーション全体で保持されないため、処理するのが最も難しい領域はモデルです。本質的に、モデルはクライアント側でかなり一貫して変更されるように見えます。サーバーとの間でデータを送受信する方法を標準化することもできますが、その時点では、モデルは実際にはJavaScriptに属しておらず、サーバー側のアプリケーションに属しています。

SQLiteがアプリケーションに属する方法と同じように、誰かがJavaScriptでデータをモデル化するためのフレームワークを作成したという試みをしばらく前に見ました。Model.select（ "Product"）やModel.update（ "Product"、 "Some data ..."）のようなものでした。これは基本的に、現在のページの状態を管理するための大量のデータを保持するオブジェクト表記でした。ただし、更新すると、そのデータはすべて失われます。私はおそらく構文に問題がありますが、あなたは要点を理解しています。

jQueryを使用している場合は、Benのアプローチが本当に最適です。関数とプロパティを使用してjQueryオブジェクトを拡張し、「コントローラー」を区分化します。私は通常、それらを別々のソースファイルに入れ、セクションごとにロードすることによってこれを行います。たとえば、eコマースサイトの場合、チェックアウトプロセスの機能を処理するコントローラーでいっぱいのJSファイルがあるかもしれません。これにより、物事が軽量で管理しやすくなる傾向があります。

于 2008-09-15T13:41:24.673 に答える
2

簡単に説明します。

サーバー指向ではない GWT アプリを作成することは完全に実行可能です。サーバー指向とは、Java ベースのバックエンドを必要とする GWT RPC を意味すると想定しています。

クライアント側だけで非常に「MVCっぽい」GWTアプリを作成しました。

  • モデルはオブジェクトグラフでした。Java でコーディングしますが、実行時にはオブジェクトは JavaScript であり、クライアント側またはサーバー側のいずれにも JVM は必要ありません。GWT は JSON もサポートしており、解析と操作が完全にサポートされています。JSON Web サービスに簡単に接続できます。JSON マッシュアップの例については、2を参照してください。
  • ビューは、標準の GWT ウィジェット (およびいくつかの独自の複合ウィジェット) で構成されていました
  • コントローラーレイヤーは、オブザーバーパターンを介してビューからきちんと分離されました。

あなたの「強く型付けされた」バックグラウンドが Java または類似の言語である場合、大規模なプロジェクトでは GWT を真剣に検討する必要があると思います。小規模なプロジェクトの場合、私は通常 jQuery を好みます。GWT 1.5 で動作する今後の GWTQueryは、jQuery 用のプラグインが豊富にあるため、近い将来には変更される可能性があります。

于 2008-10-10T07:12:48.870 に答える
1

ここで何を言っているのか 100% はわかりませんが、過去 6 年間 ASP.NET を使用した後、基本的なページ レンダリングがサーバーによって行われると、私の Web ページはほとんど JavaScript によって駆動されるようになりました。私はすべてに JSON を使用し (約 3 年間使用しています) 、クライアント側のニーズにはMochiKitを使用しています。

ところで、JavaScriptはOO ですが、プロトタイプの継承を使用するため、人々はそのように評価しません。また、それは機能的でもあると主張しますが、それはすべてあなたの書き方に依存します。関数型プログラミング スタイルに本当に興味がある場合は、MochiKitをチェックしてください。JavaScript の関数型プログラミングの側面にかなり傾いています。

于 2008-08-28T15:31:35.727 に答える