Web 開発_JavaScript スキルにおけるフロントエンドフレームワークとフロントエンドライブラリに関するいくつかの考え-jsチュートリアル-php.cn

フロントエンドフレームワークといえば、私も酔っています。今、面接に行ったり、同僚と話したりするとき、私はいつもこのフレームワークに陥ります。そのフレームワークは非常に鋭いです。

もちろん、私はフレームワークを軽視しているわけではありません。それは、ただの目玉で鶏を殺すような気分です。ウェブサイトのテクノロジーはビジネスのために存在し、それ以上では意味がありません。フレームワークも同様です。テクノロジーの選択やアーキテクチャの設計において、Web サイトのビジネス開発の現実から切り離され、流行の新しいテクノロジーを盲目的に追求することは逆効果であり、Web サイトの開発を困難な道に導く可能性があります。 1 日の平均 PV が数百しかない小規模な電子商取引 Web サイトのようなものですが、「これが、あるお宝の機能です」と叫び、アプリケーションサーバークラスターを構築し、分散ファイルシステムと分散サーバーを使用します。データベースシステム... お待ちください... 高い同時実行性と大規模なデータアクセスを処理するために使用される一連の手段。言いたいのですが、それは意味がありますか？

フロントエンドフレームワークの誤解

Web サイトの価値は、Web サイトがどのように行われるかではなく、Web サイトがユーザーにどのような価値を提供できるかにあります。したがって、Web サイトがまだ非常に小さい段階で、Web サイトのアーキテクチャのフレームワークを追求することは重要です。良いものと最後のものを犠牲にすれば、得られるものが損失を上回ります。単純なページベースの製品の場合、アプリケーションは Web ページとビューの生成のみをサーバーに依存し、アプリケーションをよりインタラクティブにするために単純な Javascript または JQuery を使用するだけで済みます。の場合、JQuery フロントエンドクラスライブラリはこれだけです。実際には、高度なフレームワークを使用する必要はありません。

もちろん、フレームワークは確かに非常に便利です。重要なのは、どのフレームワークをいつ使用するかを知る必要があるということです。大企業や大規模プロジェクトの経験や成功モデルは確かに重要であり、学ぶ価値はありますが、盲目的に従うことはできません。フロントエンドフレームワークを深く理解し、どの問題を解決するためにどのフレームワークをいつ使用するかを知ることによってのみ、ターゲットを絞り、重要なポイントを突くことができます。

フロントエンドフレームワークとフロントエンドクラスライブラリの違い

フレームワークを使用する前に、クラスライブラリ (JQuery など) とフレームワーク (angularJS など) の違いを理解することが重要だと思います。

簡単に言えば、クラスライブラリは、複雑な問題を解決する機能モジュールを関数にカプセル化し、シンプルなインターフェイスを提供するなど、コードまたはモジュールレベルの再利用や複雑さのカプセル化の問題を解決します。ライブラリは、多くのカプセル化されたメソッドを提供するツールであり、それらを使用するかどうかは私たち自身に依存します。たとえ使用したとしても、コードの構造には影響しません。

このフレームワークは、パターンレベルの再利用とプログラム構成の標準化に重点を置いています。ここでのパターンは、たとえば MVC を指します。M と V の分離を実現するために、複雑な結合関係が、頻繁に変更されるビジネスコードから、内部消化のために頻繁に変更されないフレームワークに転送されます。ある分野に一連のソリューションを提供し、開発効率を向上させるためです。特定のフレームワークを使用する場合は、そのフレームワークで定められたルールに従う必要があります。

2 つの主な違いは、JQuery は DOM 操作を中心としているのに対し、フレームワーク (正確には MVC フレームワーク) はモデルを中心としており、DOM 操作は追加であるということです。したがって、モデル中心の最終目標は、ワークフローの完全な変更をもたらし、バックエンドエンジニアがフロントエンドモデルコードを記述し、インタラクションデザイナーとバックエンドデザイナーとフロントエンドデザイナーが相互作用を処理できるようにすることです。 UI デザイナー HTML ソースコードを重点的に処理し、手間をかけずにインターフェイステンプレートの形式でインタラクションエンジニアに送信できます。この一連のコラボレーションメカニズムにより、開発効率が大幅に向上します。 MVC フレームワークを使用すると、フロントエンドタスクをより適切に分離できます。

フロントエンド MVC フレームワークのアイデア

従来の MVC モデルでは、アプリケーションがモデル層 (モデル)、ビュー層 (ビュー)、および制御層 (コントローラー) に分割されることがわかっています。これらはアプリケーションシステム内でさまざまな役割を果たし、さまざまなタスクを実行します。

モデル: データモデルは、アプリケーションのビジネスロジックに関連するデータをパッケージ化するか、データに直接アクセスするために使用されます。

ビュー: ビューは、目的のためにデータを表示するために使用されます。通常、ビューに最新の機能を実装するには、ビューが監視するデータモデルにアクセスする必要があります。

コントローラー: コントローラーは、アプリケーションのフローを制御し、イベントを処理し、ユーザーの動作だけでなくデータモデルの変更も含みます。ユーザーイベントをキャプチャすることにより、モデル層に対応する更新処理を行うように通知され、モデル層に対する更新と変更がビューに通知されて、ビューに対応する変更が行われます。したがって、コントローラーはビューとモデル間の一貫性を保証します。

フロントエンドビューについての私の理解は、ページ上の要素に直接関係する部分がビューに属するということです。ページ要素を直接制御する html、CSS、および一部の JS が含まれます。モデルからデータを取得してページに表示できます。すべてのデータ変更とリクエストはコントローラーによって処理されます。

コントローラーについてはどうですか?モデルとビューの間の接着剤として、コントローラーはビューのリクエストを適切なモデルに転送し、必要に応じてビューを更新します。コントローラー自体もモデルのオブザーバーとして機能し、モデル内の変更を取得することもできます。コントローラー自体には、ページ要素を含むコードがあってはなりません。

最後に、モデルについて話しましょう。バックエンドとの通信、AJAX リクエスト、データ処理はすべてモデルの仕事です。モデル自体は、誰がビューで誰がコントローラーであるかを知りません。これは、ビューとコントローラーが呼び出すためのいくつかのメソッドを提供するだけであり、オブザーバーのビューまたはコントローラーに変更を通知します。明らかに、Model 要素と page 要素も分離されています。

MVC モデルに基づくフレームワークには多くの違いがありますが、一般に、モデルは、読み取りと書き込み、更新、削除、検証、変換などの、vier およびデータ処理ロジックに必要なデータの保存を担当します。 View は、モデルによって提供されるデータを受信して表示し、ユーザー入力を受信し、モデルが更新された後、その更新がユーザーにタイムリーにフィードバックされます。コントローラーはビジネスロジックとイベントロジックを処理します。

自分と敵を知り、適切な薬を処方しましょう

今日、フロントエンドフレームワークとクラスライブラリはますます豊富になっています。適切なフレームワークやクラスライブラリを選択することは特に重要です。人気のあるフレームワークを見つけたら、1 週間は試してみて、その後は飽きてしまいます。プロジェクトの作業には必要ありません。また数か月間は使用できなくなります。

したがって、最も重要なことは、各クラスライブラリとフレームワークの役割を理解することです。その場合、最良の方法は次のとおりです。プロジェクトで必要なときに API を学習します。

最後に、フロントエンド開発における MVC アプリケーションの制限について明確にする必要があります。単純なプロジェクトで MVC フレームワークを使用する場合、プロジェクトはより複雑になる可能性があります。もちろん、Web フロントエンドの複雑さが増し続け、フロントエンド MVC フレームワークが発展し続けるにつれて、将来の複雑なアプリケーションソフトウェア製品において、MVC フレームワークは間違いなくフロントエンドの効率の飛躍的な向上をもたらすと信じています。仕事。

上記は、フロントエンドフレームワークとクラスライブラリについての私の基本的な理解にすぎません。これらが気に入らない場合でも、フレームワークとクラスライブラリを学ぶためのより良い方法を見つけられることを願っています。一緒に進歩し、一緒に学びましょう。

記事に技術的な誤りがある場合は、修正してください。他人を誤解させるのは罪です。