Webアプリケーションのコンポーネント化(1) - 基本的な考え方_html/css_WEB-ITnose

Web アプリケーションのコンポーネント化 (1)

基本的な考え方

1. なぜコンポーネント化するのか?

フロントエンドとバックエンドはどちらもソフトウェア システム全体の一部です。ソフトウェア製品も製品であり、その研究開発プロセスには目的がなければなりません。ほとんどのソフトウェア製品は利益を追求します。製品の目標が決定されると、導入コストの削減と開発効率の向上という 2 つの方法でコストを最適化できます。

業界は、導入コストの削減について多くの研究を行ってきました。たとえば、近年非常に人気のある「脱 IOE」は、一部の高コストの高性能製品から、オープンソースで置き換えが簡単な製品クラスター。たとえば、Linux + Mono を使用して .net アプリケーションを展開し、Windows Server のコストを回避します。

業界では、開発効率の向上についてさらに研究が行われており、主に 2 つの方法があります。開発のスピードアップと変更コストの削減です。どうすれば開発をスピードアップできるでしょうか?私たちの開発が車輪の再発明ではなく、新しい製品を作るたびに既存のものを使用するものであれば、はるかに良いでしょう。変更コストを削減するにはどうすればよいでしょうか?モジュール間の関係を明確にして、変更するたびに特定の部分を変更するだけでよく、コードを変更する必要さえありません。設定を変更します。

まずソフトウェア業界ではなく、自動車製造業などの製造業を見てみましょう。自動車はどのように作られているのでしょうか。車を作る前に、最初に車を設計し、車全体をホイール、エンジン、ドア、シートなどのさまざまな部品に分解し、個別に製造して最終的に組み立てることにより、製造プロセスを短縮できます。車のタイヤがパンクして修理に出す必要がある場合、修理工はどこでも修理するのではなく、タイヤを取り外して修理するだけで、タイヤが本当にひどく損傷している場合は、すべてのプロセスを新しいものと交換するだけです。あまり時間はかかりません。

シドマイヤーは「Civilization」という非常に優れたゲームを制作しました。第 3 世代では、研究に成功した後、作業者の効率を 2 倍にするテクノロジーがあります。その名前は「交換パーツ」です。したがって、ソフトウェア業界でも、一般にコンポーネントと呼ばれる交換可能な部品を導入する必要があります。

2. 初期のフロントエンドはどのようにコンポーネント化されましたか?

サーバー側には、J2EE Bean などの多くのコンポーネント化手法があります。コンポーネントを構築した後、ワークフロー エンジンやルール エンジンなどのいくつかのメカニズムを導入して、最も基本的なコンポーネントを整理し、ビジネス プロセスに接続する必要があります。どのようなテクノロジーや言語を使用しても、サーバーのコンポーネント化の考え方には基本的に変わりはありません。具体的には、サービス、プロセス、ルール、モデルなどのいくつかのレベルがあります。

初期の表示レイヤーは基本的に静的であり、サーバーがインターフェイスを生成し、ブラウザーがそれを表示するために使用されました。したがって、この期間では、コードによって制御されるものはほとんどすべてサーバー側にあり、一部はレイヤー化されていました。無差別の人もいました。階層化されている場合、一般的な構造は次のとおりです。

この図では、JSP (または他の P、例の便宜上、この記事で関連するサーバー側テクノロジはすべて含まれています) Java システムで表される）は、ブラウザからのリクエストに応答して HTML を生成し、関連する JavaScript や CSS とともに表示します。ここで重要な点に注意してください。ブラウザは基本的にインターフェイスの形式や関連するビジネス ロジックを制御できず、他のユーザーが提供したものを表示し、必要なものを最初に適用する必要があるという厄介な状況です。

この時期の Web 開発では、フロントエンド ロジックは基本的に無視できるため、フロントエンドのコンポーネント化方法は、ASP、JSP、その他の P のいずれであっても、タグをカスタマイズして HTML コードを配置できます。行 ロジックはラベルにパッケージ化されており、ユーザーはそれを必要な場所に直接配置できます。

この時代、いわゆるコンポーネント化は基本的にタグリブの考え方に基づいており、ビジネスロジックを含む特定のインターフェイスをエンドツーエンドのコンポーネントに統合します。ロジックへのインターフェイスであり、ロジックは基本的にサーバー側で制御されます。一般的な構造は次の図に示されています。

3. SPA 時代に新たな問題が浮上

Web2.0 が徐々に普及して以来、Web フロントエンドはもはや純粋なディスプレイではなくなり、以前の C を徐々に変えてきました。Google や Microsoft のオンライン Office など、/S で実行される一部の処理は、B/S で実装できます。この複雑さの Web アプリケーションが依然として従来の方法でコンポーネント化されている場合、それは明らかに機能しません。

先ほどのコンポーネント化手法の本質を見てみましょう。これは、プレゼンテーション層とビジネス ロジック層の間の分離であり、バックエンドはビジネス ロジックを処理し、フロントエンドは純粋にプレゼンテーションのみを行います。今のままだとインターフェースとロジックがフロントエンド、ロジックがバックエンドになってしまい、かなり混乱してしまいます。純粋なロジックをコンポーネントに階層化するのは比較的簡単であることがわかっています。そのため、プレゼンテーションにロジックが混在している場合は、別のプレゼンテーション層を剥がすことができるまで階層化ポイントを進める必要があります。 。

下図に示すように、HTML、CSS、JavaScriptは実際には静的になっており、アプリケーションサーバーに置く必要がなく、専用の高性能な静的サーバーに置くことができます。開発には CDN (Content Delivery Network、コンテンツ配信ネットワーク) を使用できます。フロントエンドとバックエンド間の通信は基本的に AJAX を介して行われますが、WebSocket などの他の方法も使用できます。つまり、リフレッシュは最小限に抑えます。

この図でわかるように、実際のフロントエンドはアプリケーション サーバーから自然に分離されているため、一部の開発と進化を独立して実行することもできます。 。

現在、多くの Web プログラムが SPA (シングル ページ アプリケーション) に向けて開発されています。このタイプのシステムは通常、従来の C/S プログラムに似ており、対話プロセスがより複雑であるため、その開発プロセスは複雑です。また、いくつかの困難もあるでしょう。

では、なぜ人々は SPA をやりたがるのでしょうか?これには多くの明白な利点があり、その中心的な利点は効率です。この効率性は 2 つの側面に反映されています。まず、ユーザーにとって、この方法で作成されたものは従来のデスクトップ プログラムと同様に優れたエクスペリエンスを提供し、頻繁な操作を必要とする業界ユーザーにとっては大きな利点があります。第 2 に、以前に統合されていた一部のメニュー機能は iframe を介して導入する必要がある場合があります。ただし、各 iframe はいくつかのパブリック ファイルを個別に導入する必要があり、サーバーのファイル転送には大きな負荷がかかります。環境を初期化する必要がありますが、これは非常に無駄であり、相互に通信するのに不便です。通常、postMessage などを介してやり取りする必要があります。

たとえば、SPA では、インターフェイスを HTML フラグメントにすることができ、AJAX を使用してロードして処理し、インターフェイス上に配置できます。論理的な JavaScript コードがある場合は、実行時にそれをロードする必要があるなどの非同期ロード メカニズムを使用することもできます。全体的なアイデアはより優れています。

そのようなニーズには、jQuery を使用し、非同期の js 読み込みフレームワークを追加すれば十分ではないかと多くの人が言います。これら 2 つをうまく活用すれば、いくつかの問題を解決することもできますが、最も重要なことには対処していません。 Webシステムではプレゼンテーション層はHTMLとCSSなので非常に自然で、ファイル分離だけを見るとロジックを別のjsファイルに配置して書かないようにすることもできます。 html 内で、これはフロントエンド コードを分割する以前の主流の方法でした。

先ほど、SPA の開発過程でいくつかの困難に遭遇すると述べましたが、これらの困難は大幅に複雑化したためであり、それがいくつかの問題を引き起こしていると考えている人もいます。純粋なインターフェイスなど、コントロールはそれほど単純ではなく、より複雑であると言われています。何が問題ですか?たとえて言えば、コンピューター上で 2 つのエクスプローラー ウィンドウを開き、同じディレクトリを参照し、一方のディレクトリにあるファイルを削除すると、そのファイルがもう一方のディレクトリで更新されるかどうかわかりますか。

更新されることは間違いありませんが、使用している Web ページを見ると、複雑なシステム全体を 1 つのページに統合すると、データの更新が確実に反映されます。リアルタイムで使用しているすべてのユーザーに戻りますか?どうすれば頭が痛くなりますか？コード構成の複雑さは大幅に増加しているため、アーキテクチャをいくつか改善する必要があります。

4. アーキテクチャの変更

アーキテクチャに関しては、通常、デザイン パターンを思い浮かべます。有名な書籍「デザイン パターン」では、クライアント開発を扱うための典型的なシナリオが冒頭で説明されています。それが MVC です。

Struts のおかげで、Web 分野には比較的古典的な MVC アーキテクチャもあり、ここでの V はフロントエンド レンダリング全体を担当します。 -side レンダリングは HTML を出力するだけです。以下の図に示すように:

SPA 時代では、これは適切ではなくなったため、ブラウザーは独自の MVC およびその他のレイヤーを形成し、ここでの V はクライアント側になりました。通常、これを実装するにはクライアント側の HTML テンプレートが使用され、それに応じてブラウザ側でモデルとコントローラーが形成されます。

Backbone、Knockout、Avalon、Angular など、このレベルのフレームワークは数多くあります。これらはさまざまな設計アイデアを採用しており、MVC、MVP、およびMVVM にはそれぞれ独自の特徴があります。

Angular を例に挙げると、ビューとモデル間の関連付けを実現するために双方向バインディングを使用することが推奨されています。このようにして、異なるビューが同じモデルにバインドされている場合、前述の問題は解決されます。モデル自体も、特定のメカニズムを通じて他の論理モジュールと連携します。

このメソッドは依存性注入です。依存関係の注入の中心的な考え方は、構成を通じて依存コンポーネントをインスタンス化することです。このモデルを使用してソフトウェア アーキテクチャを設計すると、パフォーマンスと追跡とデバッグの利便性がある程度犠牲になりますが、その代わりに比類のない疎結合と代替性が得られます。

たとえば、これらのコンポーネントを個別にテストし、圧力をかけずに使用するときに導入できます。特定の分野に従事する企業にとって、これだけでも、フィールドモデルで頻繁に変更されないすべてのビジネスコードが維持されるのは一種の富です。

5. MV* フレームワークの基本原則

Angular のようなフロントエンド フレームワークを設計する場合、どのように始めればよいでしょうか?当然のことですが、ロジック制御にはJavaScriptというフレームワークを使用する必要があり、最も重要なのはそのロジック処理方法です。

なぜインターフェースをカラフルにできるのでしょうか? HTML と CSS があるので、この 2 つは設定形式で記述されていることに気付きました。バックエンドの依存関係インジェクションを参照して、この 2 つを Spring フレームワークの XML に相当する設定ファイルと考えると、アイデアが突然生まれます。明らかになる。

バックエンドとは異なり、フロントエンド ロジック ツールとして機能する JavaScript はエントリ ポイントとして使用できず、実行するには HTML 内でハングする必要があるため、奇妙な状況が発生します。ロジックは最初に設定ファイル (HTML) にハングすると、別のコンテナ (ブラウザまたは Hybird シェル) が最初に設定ファイルをロードし、その後、特定のエントリからロジックを実行できます。良いニュースは、このステップの後、ロジック層が輝き始めるということです。

ここから、フレームワークが何をするのかが始まります。

• 自身を初期化します (ブートストラップ)
• まだ導入されていない可能性がある JavaScript コードを非同期的にロードします (必須)
• HTML で定義されたルールを解析します (テンプレート パーサー)
• モデルのインスタンス化 (スコープ)
• モデルと DOM 間の関係の作成 (バインディング、インジェクション)

これらが主なプロセスであり、いくつかのプロセスがあります

• URL の検索文字列を解析し、ステータス (ルート) を復元します
• HTML パーツのテンプレート (テンプレート URL) を読み込みます
• パーツテンプレートとモデルの関連付け(バインディング)

6. コンポーネント化のやり方

6.1. HTMLのコンポーネント化

SPAの代表的な機能は、部分的なロード、および 1 つのリングのインターフェイスのコンポーネント化も重要です。インターフェイス フラグメントが動的に要求された後、テンプレート エンジンなどのテクノロジーを利用した何らかの変換を通じて、メイン インターフェイス上の対応する場所に配置されます。したがって、この観点から見ると、HTML のコンポーネント化、つまりインターフェイスの断片化とテンプレート化は非常に理解しやすいものになります。

6.2. JavaScript のコンポーネント化

JavaScript のこの部分にはいくつかの開発段階があります。

• 初期の共有ファイル、パブリック関数のコードを提案、複数のページで共有
• 動的参照、グローバル変数の削除
• いくつかのフレームワークのさらに詳細な分割、たとえば、Angular はプロバイダー、サービス、ファクトリー、コントローラーに分かれています

JavaScript コンポーネント化の目的は何ですか? それは、責任が明確であり、疎結合であり、単体テストと再利用が容易であることです。ここでの疎結合は、JS コードだけでなく、JS と DOM の間の関係にも反映されます。そのため、Angular のようなフレームワークには、DOM 操作をこのタイプのコードに制限するディレクティブの概念があります。 DOM を操作します。

上の図のように、まずレイヤーに分割し、その後レイヤーに分割するのが原則です。これを行うと、エンドツーエンドのコンポーネントは存在しなくなりますが、以前ほど使いやすくはありませんが、他の多くの点で改善されています。

6.3. CSS のコンポーネント化

業界では、LESS、SASS、Stylus などの研究も数多く行われています。 CSS をコンポーネント化する必要があるのはなぜですか?従来の CSS はフラットなテキスト構造であり、たとえば構造を緩やかな構造からコンパクトな構造に変更したい場合は、多くの変更を加える必要があります。実際に使用される CSS は出力結果としてのみ考慮され、中間プロセスとしての変更に適した別の方法があれば、はるかに優れています。たとえば、いくつかのものを変数として定義し、各詳細要素でこれらの変数を使用します。全体的な変更が必要な場合は、これらの変数を変更して再生成するだけで済みます。

上記では、Web フロントエンド開発のコンポーネント化の一般的な概念について説明しました。コンポーネント化後のコラボレーション プロセスと制御メカニズムについて詳しく説明します。