私の建築体験シリーズの記事-htmlチュートリアル-php.cn

フレームワークレベル: フロントエンドが近年急速に発展しているのは、JS が 10 年前のおもちゃではなくなったからです。以前は、リッチクライアント RIA のアプリケーションは、Flash/Flex や Silverlight を使用することで、JS を使用してほとんどの機能を完了できるようになりました。そのため、フロントエンドサポート言語としての JS は、単なるコーディングではなく、フレームワークとしての機能がますます増えています。登場する。ますます多くの開発モデルが、バックエンドが JSON データソースを吐き出すだけで、フロントエンドが UI に関するすべてのことを行うという状況に変化しています。

MVC
MVC は、責任の分離を実現するのに適しています。フロントエンドがすべてのレンダリングとフロントエンドビジネスロジックを担当する Web サイトでは、MVC フレームワークを使用することもできます。とても有益です。現在、JavaScript 用の MVC フレームワークが多数あります。実際には各フレームワークには独自の特徴がありますが、フロントエンド MVC フレームワークはバックエンドのものとは多少異なります。たとえば、フロントエンド MVC フレームワークは M 要素と V 要素の双方向バインディングを行うことがありますが、バックエンドでは多くの場合一方向です。 MVC フレームワークを導入することで、同じページ上で多くのことができるようになります。また、MVC を明確に分離し、M の概念を強調することもできます。という枠組みなしで行われます。

通信
より複雑なページの場合、モジュール間で通信したい場合は、より多くの Javascript モジュールが存在する可能性があります (たとえば、左側のメニューの最初のレベルのカテゴリをクリックすると、左側のメニュー、ナビゲーション、リストがページに表示されます)。、ナビゲーションに通知する必要があります。この項目を追加すると、通知リストがデータを再読み込みして更新され、この選択をナビゲーションから削除します。通知リストにデータを再取得する場合は、通知メニューにすべてが表示されます。。より複雑な通信の場合、モジュールが強く結合されて他のモジュールの関数を直接呼び出す場合、各モジュールを変更した後に情報を公開するパブリッシュおよびサブスクライブのメカニズムを導入できると思います。この情報を気にする人は、この情報をサブスクライブし、コールバック関数で対応する操作を実行できます。 Amplifyjs をパブリッシュおよびサブスクライブフレームワークとして使用できます。

テンプレート
フロントエンドでも、バックエンドと同様に、スクリプト内に HTML が混在することが多いのが問題です。個人的には、非常に些細な DOM の変更であれば、これが当てはまると思います。大きな問題ではありません。HTML のブロックが結合されたり、データと HTML、さらには CSS が混在したりすると、コードの保守性が非常に悪くなります。現時点では、Twitter hoganjs などのいくつかのテンプレートエンジンを使用してデータとパフォーマンスを分離することを検討できます。 Big Beard エンジンなどの多くのテンプレートエンジンはフロントエンド用だけでなく、バックエンド言語用の対応するエンジンも備えているため、フロントエンドとバックエンドでテンプレートをテキストファイルに配置することもできます。これは、コードがサーバー側のレンダリングに偏っている場合は、将来クライアント側のレンダリングに変更する場合は、バックエンドでテンプレートを使用することを意味します。フロントエンドによって直接使用されます。

クラスライブラリ
フレームワークに加えて、jquery、underscore、linq などの多くのクラスライブラリがあります。これらのフレームワークをうまく活用すると生産性が大幅に向上し、スクリプトは実際に想像以上のことを実行できます。私はバックエンドの仕事をしていますが、フロントエンドについてはあまり知りません。

依存関係
Requirejs や Commonjs などのコンポーネントを使用して、スクリプト間の依存関係を管理できます。私たちのモジュールには、依存する必要があるものを明確に記述するだけでよく、Requirejs は、それらを特定のファイルにロードするのに自然に役立ちます。コンポーネントの順序やバージョン番号を気にする必要はありません。 Requirejs をベースにしているため、静的リソースをマージする場合でも、コンポーネントを構成を通じて同じサーバーで生成されたパスに設定するだけで十分に処理できます。 .js 拡張子が自動的に追加されますが、Requirejs ソースコードを変更することで完全に解決できます。アーキテクチャに関して言えば、オープンソースのものを使用しているので、問題が発生した場合にソースコードを変更することを恐れるべきではないというのが私の考えです。私たちはフレームワークのユーザーとして立ち止まってはなりません。フレームワークをカスタマイズしたり、独自のコードを作成者に提供したりすることさえ、それほど難しいことではありません。デザインレベル:

職務の分離の概念
CSS スタイル、JS の動作、HTML 構造については誰もが知っていますが。個人的には、HTML のみが必要だと思います。つまり、ページにスタイルやスクリプトがない場合は、そのページで表現する必要がある内容を大まかに表現できる明確なページである必要がありますが、見た目は悪く、インタラクティブです。多くの機能が Ajax によって実装されている場合、インタラクティブな作業はサーバーに転送され、サーバー側レンダリングが実装されます。スタイルが増えるとレイアウトの見栄えが良くなるだけで、スクリプトが増えるとインタラクティブになるだけで、ページを更新する必要はありません。ただし、スタイルが少ないからといって Web サイトが役に立たないというわけではありません。現在、同じ目的を持ったコンセプトがたくさんあります。この状態に到達できない場合は、少なくとも css、js、html に責任を明確に果たさせ、無関係なコンポーネントに多くのことを与えないようにする必要があります。たとえば、操作スクリプトコードを HTML に含めないようにし、スクリプト内で DOM 要素を直接選択して、スクリプトに HTML コードの大きなセクションを含めないようにしてください。代わりに、テンプレートから読み取って入力する必要があります。また、HTML コードに多数の埋め込みスタイルを含めないようにしてください。代わりに、スタイルの割り当てをセレクターを通じて選択する必要があります。

階層とディレクトリ構造
比較的複雑で大規模なプロジェクトの場合、ディレクトリ構造を合理的に計画することも非常に重要です。スクリプトとスタイルは 2 つのディレクトリに分割できると言われるかもしれませんが、複雑なプロジェクトに数百ものディレクトリがある場合は、すべてのスクリプトは 1 つのフォルダーにリストされていますか?バックエンドには階層化の概念があります。実際には、フロントエンドにも階層化の概念があります。さらに、次のようなデータアクセス Ajax 層があります。もちろん、定数ファイルも存在します。フロントエンドは、iOS または Android プログラムの非常に大規模なプロジェクトに依存できると思います。例えば、以前作ったiOSプログラムの例では、このような階層化は比較的わかりやすいと個人的には思います。

統合と分割のバランス
多くの場合、建築的なものはトレードオフになります。固定された基準がある場合、建築家は必要なくなります。固定された基準に従って行うだけで済みます。たとえば、1 つのページで 10 個のスクリプトファイルと 5 個のスタイルファイルが使用されている場合、それらを 2 つのファイルにマージすることで最小限のリクエスト数を達成できるのは当然ですが、これは必ずしも良いことなのでしょうか?これら 10 個のスクリプトと 5 個のスタイルファイルの多くは、他のページで共有されている可能性があります。単純に結合すると、ユーザーのダウンロードトラフィックが増加する可能性があります。そのため、共通のものを 1 つのファイルに統合し、フレームワークファイルを分離する方法を考えてください。各ページには独自のスクリプトとスタイルがあり、これも一種の知識です。パフォーマンスレベル:

パフォーマンステスト
YSlow や PageSpeed などのツールは、フロントエンドのパフォーマンスの問題を分析できますが、ここでは説明しません。フロントエンドの場合は、ユーザーのクライアント環境やネットワーク環境が関係するため、状況はそれほど単純ではありませんが、できることは、ユーザーのドメイン名解決の数を最小限に抑え、制御可能な範囲内でユーザーがダウンロードするデータの量を減らすことです。同時実行性などを向上させます。実際、端的に言えば、私たちはパイプを掃除してパイプを大きくしたり、パイプを追加したり、パイプ内の水を減らしてパイプをよりスムーズに流そうとしています。

パフォーマンス分析
現在、dynaTrace AJAX Edition など、JavaScript のパフォーマンスや DOM 解析の詳細な分析を実行できるツールがいくつかあり、開発の観点からスクリプトコードとページレイアウトが妥当であるかどうかを分析できます。フロントエンドコードを完全に理解し、最適化するために。クライアントのリソースはサーバーのリソースほど重要ではありませんが、ユーザーにより良い機械的エクスペリエンスを提供するには、クライアントのパフォーマンス消費を最適化することが最善です。