単一ページのJavaScript Webアプリケーションのアーキテクチャですか？

Question

複雑な単一ページJS Webアプリケーションをクライアント側でどのように構成する必要がありますか？具体的には、モデルオブジェクト、UIコンポーネント、コントローラー、およびサーバーの永続性を処理するオブジェクトの観点から、アプリケーションをきれいに構造化する方法に興味があります。

MVCは最初はぴったりのようでした。しかし、さまざまな深さでネストされたUIコンポーネント（それぞれ独自の方法でモデルデータに作用/反応し、それぞれが直接処理するイベントまたは生成しないイベントを生成する）では、MVCをきれいに適用できるとは思えません。（ただし、そうでない場合は修正してください。）

-

（この質問は、最も単純な1ページのアプリ以外に明らかに必要なajaxの使用に関する2つの提案をもたらしました。）

Dean Burge · Accepted Answer

PureMVC/JS のMVCアーキテクチャは、最もエレガントなIMOです。私はそれから多くを学びました。 Scalable JavaScript Application Architecture Nicholas Zakasによるクライアント側のアーキテクチャオプションの調査にも役立つことがわかりました。

他の2つのヒント

ビュー、フォーカス、および入力管理は、単一ページのWebアプリで特に注意が必要な分野であることがわかりました
また、JSライブラリーを抽象化して、使用するものの考え方を変えたり、必要に応じて組み合わせたりすることもできます。

Hasith · Answer

Deanが共有しているNicholas Zakasのプレゼンテーションは、出発点として非常に良い場所です。私もしばらくの間同じ質問に答えるのに苦労していました。いくつかの大規模なJavaScript製品を実行した後、誰かが必要とする場合に備えて、学習を参照アーキテクチャとして共有することを考えました。見て：

http://boilerplatejs.org/

次のような一般的なJavascript開発の懸念に対処します。

ソリューションの構造化
複雑なモジュール階層の作成
自己完結型UIコンポーネント
イベントベースのモジュール間通信
ルーティング、履歴、ブックマーク
単体テスト
ローカリゼーション
ドキュメント生成

等.

Joeri Sebrechts · Answer

アプリの作成方法：

ExtJSフレームワーク、シングルページアプリ、個別のJSファイルで定義されたすべてのコンポーネント、オンデマンドでロード
すべてのコンポーネントは、独自の専用Webサービス（複数の場合もあります）にアクセスし、データをExtJSストアまたは専用のデータ構造にフェッチします
レンダリングでは標準のExtJSコンポーネントが使用されるため、ストアをグリッドにバインドしたり、レコードからフォームをロードしたりできます。

JavaScriptフレームワークを選択して、ベストプラクティスに従うだけです。私のお気に入りはExtJSとGWTですが、YMMVです。

このための独自のソリューションを展開しないでください。最新のjavascriptフレームワークが行うことを複製するために必要な労力は大きすぎます。すべてをゼロから構築するよりも、既存のものを適応させる方が常に高速です。

Prakash Tiwari · Answer

Question - What makes an application complex ?

回答-質問自体での「複雑な」Wordの使用。したがって、一般的な傾向は、最初から複雑なソリューションを探すことです。

Question - What does the Word complex means ?

回答-不明または部分的に理解されているもの。例：今日でも重力の理論は私にとって複雑ですが、1655年にそれを発見したアイザックニュートンirにとっては複雑ではありません。

Question - What tools can I use to deal with complexity ?

回答-理解とシンプルさ。

Question - But I understand my application . Its still complex ?

答え-理解と複雑さが共存しないため、考え直してください。巨大な巨大なアプリケーションを理解しているなら、それは小さな単純なユニットの統合に他ならないことに同意するでしょう。

Question - Why all of the above philosophical discussion for a question on Single Page Application (SAP)?

回答-なぜなら、

-> SPAは、アプリケーション開発で行っている多くのことのために車輪を再発明する必要がある、新しく発明されたコアテクノロジーの一種ではありません。

-> Webアプリケーションのパフォーマンス、可用性、スケーラビリティ、および保守性を向上させる必要性に駆動される概念。

->かなり新しく識別された設計パターンなので、SPAの設計パターンとしてのSPAの理解は、SPAのアーキテクチャに関する十分な情報に基づいた決定を下すのに大いに役立ちます。

->ルートレベルでは、複雑なSPAはありません。アプリケーションのニーズとSPAパターンを理解した後、アプリケーションを作成していることに気付くでしょう。以前と同じように、いくつかの修正と再配置を行います。開発アプローチで。

Question - What about the use of Frameworks ?

回答-フレームワークは、いくつかの一般的に特定された一般的なパターンのボイラープレートコード/ソリューションであるため、アプリケーション開発からx％（アプリケーションに応じて可変）の負荷を取り除くことができますが、特に重い場合はあまり期待できません成長するアプリケーション。アプリケーションの構造とフローを完全に制御するのは常に良いケースですが、最も重要なのはそのためのコードです。アプリケーションコードに灰色または黒色の領域がないようにします。

Question - Can you suggest one of the many approaches to SPA architecture ?

回答-アプリケーションの性質に基づいて独自のフレームワークを考えてください。アプリケーションコンポーネントを分類します。派生したフレームワークに近い既存のフレームワークを探します。見つかった場合は使用し、見つからない場合は独自のフレームワークを使用することをお勧めします。フレームワークの作成は最初はかなりの努力ですが、長期的にはより良い結果を生み出します。 SPAフレームワークの基本的なコンポーネントは次のとおりです。