JavaScript クライアントコードに対する代替の「アーキテクチャ」アプローチは?

https://stackoverflow.com/questions/32540

09-06-2019
|

質問

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

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

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

しかし、私は他の人がより充実した JavaScript アプリをどのように構築しているかに非常に興味があります。私は GWT やその他のサーバー指向のアプローチには興味がありません...「JavaScript + <汎用 Web サービス - ここにあるもの>」というアプローチだけです。

注記：先ほど、JavaScript は「実際には OO ではなく、実際には機能しません」と言いました。これは皆の気を紛らわせたと思います。JavaScript は多くの点で独特であり、私は強く型付けされたバックグラウンドを持っているので、私が知っているものの、まったく異なる言語で開発されたパラダイムを強制したくありません。

解決

..しかし、JavaScript には多くの側面があります。はああ。

このことを考慮：

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

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

私はこの手法を使用して、独自の状態を持つページレベルの JavaScript クラスを作成しました。これは、クラスの包含を維持するのに役立ちます (また、再利用して他のクラスに配置できる領域を特定することもよくあります)。

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

他のヒント

JavaScriptMVC は、大規模な JS アプリケーションを編成および開発する場合に最適です。

建築設計は非常によく考えられています。JavaScript を使用して行うことは 4 つあります。

イベントに応答する
データのリクエスト/サービスの操作 (Ajax)
ドメイン固有の情報を ajax 応答に追加します。
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({後: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 の統合テスト
ドキュメンテーション
スクリプト圧縮
エラー報告

MochiKit は素晴らしく、js ライブラリに関する限り、いわば私の初恋でした。しかし、MochiKit は非常に表現力豊かな構文を備えていますが、Prototype/Scriptaculous や jQuery ほど快適ではないと感じました。

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

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

これまでのところ、次のようなものを使用したアプローチには非常に大きな違いがあることがわかります。内線, 、など JQuery UI, 聖書的な, もちキット, 、など。

Ext では、HTML は単なる 1 つのプレースホルダーであり、UI がここに配置されます。あれから、 すべて JavaScriptで記述されています。DOM インタラクションは、別の (おそらくより強力な) API レイヤーの下で最小限に抑えられます。

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

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

これらのライブラリの多くには、興味深いモジュール化技術も含まれていることに注意してください。非常に明確な説明が Ext Web サイトに寄稿されています。モジュールを使用してコードを「保護」する素晴らしい方法.

私が完全に評価した新しいプレーヤーはスプラウトコア. 。DOM が非表示になり、主にプロジェクトの API を処理したいというアプローチでは Ext のように見えます。

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

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

jQuery を使用している場合は、Ben のアプローチが最適です。jQuery オブジェクトを関数とプロパティで拡張し、「コントローラー」を区分化します。通常、これを行うには、それらを別々のソースファイルに入れ、セクションごとにロードします。たとえば、電子商取引サイトの場合は、チェックアウトプロセスの機能を処理するコントローラーが満載された JS ファイルがある可能性があります。これにより、処理が軽量になり、管理が容易になる傾向があります。

簡単な説明です。

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

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

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

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

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

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow

JavaScript クライアント コードに対する代替の「アーキテクチャ」アプローチは?

JavaScript クライアントコードに対する代替の「アーキテクチャ」アプローチは?