複雑なクライアントアプリケーションを構築する方法論への3つのアプローチ

おそらく、誰にも合う単一のレシピはありません。 これはあらゆる問題に適用されます。 開発者にとって、この論文は自明であり、個々のツールの使用と設計への関与は主にプロ意識によって決定されます。 自転車の発明はロマンチックで避けられません。



特に、自転車の発明は、アプリケーションの複雑さの増加が徐々に、ある意味でいつの間にか発生するときに起こります。 複雑なアプリケーションは通常、リッチアプリケーションであり、その要素と機能はW3C www.w3.org/TR/backplaneで指定されています。 有名なJavaScriptエバンジェリストのAddy Osmaniは、さらに複雑なアプリケーションを定義しています：「私の意見では、大規模なJavaScriptアプリケーションは、サポートに多大な開発者の努力を必要とする重要なアプリケーションです。 com / largescalejavascript /）。





デスクトップアプリケーションの場合、開発プロセスが確立されているようです。 ネットワークアプリケーションの場合、一般的なスキームも明確です。 しかし、マークアップ言語と使いやすさの非公式の概念で表現されたウェブの技術的特徴は、リッチなアプリケーションの理解と説明を複雑にします。 アプリケーションのネットワーク性の特徴。リアルタイム機能は技術的要因によって制限され、データへの即時アクセスはありません。 クラスのネイティブ構造を持たないJavaScriptオブジェクト言語の機能。 パフォーマンスと機能に影響するさまざまな環境（つまり、ブラウザー）での展開と実行の特殊性は、明らかにこれらのすべての要因が、クライアントアプリケーションの能力を決定し、その設計の一般的な設計（pathosのくず）を開発することを初期に妨げていたようです



たとえそれがそうであっても、私はそれをそれほど一般的に見ない。 代わりに、いくつかの異なる概念を理解しています。 1つ目は、有名なMVC（Model View Controller）設計スキームです。 2番目は、Nicholas Zakasからの論理的なコード分離の概念です（Yahooカンファレンスwww.youtube.com/watch?v=vXjVFPosQHwで話しています）。

3つ目は、データが混在し、インターフェイス要素とさまざまな機能で動作するコードを作成するための単純なアプローチです（混在すると悲劇的に「パスタ」が発生する場合があります）。



さらに、これらのアプローチにおけるコードの編成と機能の編成とは何であるかという問題がかなり細かく言えます。



MVCスキーム（Model Representation Controller）は、いくつかの成功したJavaScript実装を見つけました。backbone.js、JavaScriptMVC。 スキームについて簡単に説明します。 モデルの構造と階層にはデータが含まれており、ビューには、ユーザーに送信されるこのデータのバージョンが表示されます。 モデルとビューの間には直接的な接続はありません。これは、コントローラーという形の中間体が存在するためです。イベントを管理し、複数のビューを管理したり、制御を別のMVCモジュール（階層MVCスキーム）に転送したりできます。







コントローラーの制御機能は、わずかに異なるモデルMVP（モデルビュープレゼンター）を導き、次にMVVM（モデルビューViewModel）を導きました。 MVVMは、モデル側とビュー側の両方のイベント中にデータを同期するView-Model（または必要に応じてVisible Model）の形式で、モデルとビュー間のより緊密な接続によって区別されます。







MVVMは、Silverlightについて説明されており、アプリケーションロジックとは異なる特定のロジックを持つ複雑なインターフェイスに利点があります（たとえば、オブジェクトをモデルに追加すると、アプリケーションインターフェイスが大きく変わります）。 HTMLの場合、MVVMスキームはDOMのおかげで特に成功しています。DOMには、ご存じのとおり、データが含まれている場合があります。 したがって、MVVMはknockout.jsフレームワークに正常に実装されました。 最初は、すべてが簡単です。 サーバーによって提供されるデータモデルがあります。 DOMの形式で、マークアップの形式で表現があります。 また、表現の変更を説明し、モデルとプレゼンテーションを接続し、この接続を同期するRepresentation-Modelがあります。

MVCは、アプリケーションの3つのレベルの分離として単に解釈でき、それらの間の関係を規制できないことに注意してください。 そのため、多くの場合、モデルとビューが矢印で接続されている図がありますが、この方法では、異なるビューとコントローラーの階層を使用する場合に有用なスケーラビリティプロパティが失われることは明らかです。 これについての詳細は、iOS用アプリケーション開発に関する最初のPaul Hegarty講義www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259で非常に明確に述べられています。



Nicolas Zakasは彼の開発提案を発表しました（パターンの言語への形式化はAddy Osmani addyosmani.com/largescalejavascriptの記事にあります）。 実際、彼は一般的なモデルとロジックから逃れ、「分割統治」アルゴリズムを使用することに決めました。アプリケーション要素はインターフェースブロックで装飾され、それぞれが独自のモジュールで実装されます。 これらのモジュールは相互に交換しません。 彼らは、実行されたサンドボックスについてのみ知っています。 サンドボックスは、アプリケーションのコアを処理し、プロセスを起動して一連のアクションを監視します。 コア自体はチェーンの最後ではありません（呼び出し）。以下に、jQueryなどの環境での技術的な作業のための標準ライブラリとプラグインがあります。 モジュラーアプリケーションの場合、AMDモジュール仕様仕様（および代替CJS）が作成されました。







同じ「分離」アプローチによる3番目のオプションを提案させてください。 オブジェクトを（広義には）アクター、機能、およびスクリプトに区別します。 アクターは、グラフィカルな解釈におけるアプリケーションの一部です。 それらをウィジェットと呼ぶことは危険です。 アクターには自身に関する情報があり、その中にデータが配置されます。 機能は、類似のウィジェットの可能な変換のリストであり、各機能はアクターにアタッチできます。 これらの機能の呼び出しはスクリプト内で発生します。 スクリプトはアクターに依存する場合があり、初期化する場合があります。 単に連続した関数呼び出しをリストします。 タスクの複雑化の可能性があるスケーリングの観点から、これが最適な方法ではないことは明らかです。 （しかし、私の意見では、これは自転車を作成する最も明白な方法です。）







スケーラビリティが達成される場所

Zakas自身が説明したように、彼の大規模アプリケーションのアーキテクチャの大きな利点は、jQueryなどの標準ライブラリを構築し、問題なくそれらを変更し、Application Coreのレベルをわずかに修正できることです。 モジュールを追加してオフにするのは簡単です。

MVVMモデルでは、非常に厳格な「垂直」が見られます。インターフェイスを変更すると、3つのコンポーネントすべてを記述する必要があります。 ただし、既に説明した要素は問題なく変更できます。 同時に、インターフェイスグラフィックスの完全な再描画がそのロジックに影響を与えない場合、最もスケーラブルで最も柔軟な部分はプレゼンテーションレベルです。

素朴なアプローチでは、実装の3つのオブジェクトすべての必須記述を定義する厳しいバンドルもあります。 しかし、最も柔軟な部分は、非常に簡単に変更できるシナリオのレベルのようです。



メインロジックはどこに規定されていますか

[コメンテーターのおかげで、このブロックの大部分は修正されました！]

Zakasモデルでは、ビジネスロジックとUIはモジュールに実装されます。

MVCでは、ロジックはモデルに配線され、コントローラーに配置することもできますが、批判されるだけです（ソースを参照）。 対照的に、MVVMでは、ロジックはViewModelの「中間」レイヤーに配置されます。

単純なアプローチでは、ロジックはシナリオに分割され、UIはプリミティブな機能に分割されます。



多くのユーティリティコード、フレームワークの理論的なボリュームの推定値はありますか

Zakasモデルでは、フレームワークはモジュールとサンドボックス（「環境での起動」）のサービス接続、およびアクションの主要なタイプを記述するカーネルを記述します。

MVCは、モデルとビューのメインクラスの説明を前提としています。 コントローラーの一部の機能もフレームワークに実装する必要があります（MVVMモデルの同期など）。

素朴なアプローチには、アクターとそれらに付加された機能の「アセンブリ」の実装を含める必要があります。



部品のテストのしやすさ

モジュール方式は、テストシナリオを完全に認識します。回路の各部分は個別にテストでき、各モジュールも同様にテストできます。

MVCは、コントローラーとの相互作用のレベルによって「部分的に」テストすることもできますが、これはボリュームの観点からはより「難しい」テストです。

素朴なアプローチは、個々のウィジェットの機能をテストするように適合されています。 スクリプトのテストは、テストの分岐およびあいまいな初期状態により、より複雑になる可能性があります。



コードは本当に再利用可能ですか

モジュール方式のアプローチにより、完全にスケーラブルなモジュールソリューションが作成されます（さらに、アプリケーションだけでなくインターネット全体でAMDを使用する場合）。 その後、コードを別のプロジェクトの一部として別のメインライブラリ（YUIなど）に部分的に適用できます。

MVCは、プレゼンテーションのレベルを変更および置換する場合に、そのタスク内でのみスケーリングできます。

素朴なアプローチは、さまざまなアクターで再利用できる個別の機能を作成します。 アクターの階層を構築できます。 シナリオは「1回限り」です。



この表面的な分析を深めたいと思います。 間違って反映した点は何ですか？ どのメソッドがより詳細な説明を持っていますか？ すべてのコメンテーターに、MVC、MVVM、およびモジュール方式のアプローチでの経験を共有するようお願いします！



UPD

mark_ablovは、MVCアプローチとモジュール性アプローチの間の私には明らかでない接続を提案しました。特に、MVC回路にモジュールを実装できます。 合計、このような図を取得できます。





ソース



habrahabr.ru/blogs/webdev/117791

blog.rebeccamurphey.com/code-org-take-2-structuring-javascript-applic

addyosmani.com/largescalejavascript

nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm

www.w3.org/TR/backplane

Alex WebCaw、JavaScript Webアプリケーション。 クライアントへの状態の移動に関するjQuery開発者ガイド、2011年

www.youtube.com/watch?v=vXjVFPosQHw （ビデオ）

www.intuit.ru/department/internet/aspnetmvcframe/1 （ビデオ）

www.stanford.edu/class/cs193p/cgi-bin/drupal/node/259（iTunes 、ビデオ）

blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-appreciated（PHP 、シックコントローラーの批判）

martinfowler.com/eaaDev/uiArchs.html