フロントエンドフレームワークの開発履歴

フロントエンドMV *フレームワークの意味



Meaning Front End Mv Framework



フロントエンドでMV *に取り組むことの重要性は何であるかという質問がよくあります。一部の人々は質問を提起しました：AngularJS、Knockout、およびBackBoneによって表されるMV *フレームワークと、jQueryのようなフレームワークの違いは何ですか？私はjQueryをうまく使用しましたが、このフレームワークを導入する必要がありますか？



これらの質問に答える前に、まずいくつかの歴史を明らかにする必要があります。フロントエンドにフレームワークがあったのはいつですか？

初期のフロントエンドは比較的単純で、基本的にページはワークユニットであり、コンテンツは主にブラウズタイプであり、場合によっては単純なフォーム操作があります。この時期、各インターフェースにはJavaScriptロジックがわずかしかなく、フレームワークはそれほど必要ありません。 AJAXの出現とWeb2.0の台頭により、人々はページ上でより複雑なことを実行できるようになり、インターフェイス、リモートリクエスト、データでの一般的なDOM操作のためのフロントエンドフレームワークが実際に表示されます（jQueryで表されます）。処理はカプセル化されており、データの処理に焦点を当てたアンダースコアもあります。厳密に言えば、これらはフレームワークではなく、ライブラリです。



ライブラリとフレームワークの間にはいくつかの違いがあります。ライブラリは私が提供するツールであり、使用する必要はありません。使用しても、独自のコード構造には影響しません。フレームワークはドメイン用であり、ソリューションを提供します。あなたが私を使うなら、あなたは私のやり方で物事をしなければなりません。この定義によれば、jQueryとUnderscoreはどちらも、ライブラリ、ExtJS、およびdojo計算フレームワークとのみ見なすことができます。

MV *フレームワークが上昇しているのはなぜですか？その出現は、アプリケーションの方向でのいくつかのWeb製品の開発とともに、C / Sフィールドで同じ問題に遭遇しました。フロントエンド機能の強化、コードの拡張のために、それは 'を実行する必要があります。フロントエンドアーキテクチャのこと。

バックエンド開発を行う多くの人々は、フロントエンドアーキテクチャについて非常に軽蔑しています。彼らは、フロントエンドは単なる薄い層であると考えています。アーキテクチャは何をしますか？アーキテクチャに従事するだけでなく、MVCに従事するためにも何が必要ですか？ Java StrutsのMVCでは、フロントエンド全体をビューと見なすことができます。また、このビューでモデルとコントローラーなどを分割する必要がありますか？それらのほとんどはこれについて非常に軽蔑していますが、Webフロントエンドの複雑さが増すにつれて、多くの場所がクライアントと本質的に異ならないようになりました。



jQueryの考え方は次のとおりです。DOM操作に焦点を当てる

MV *フレームワークについての考え方は次のとおりです。モデル中心のDOM操作が添付されているだけです

さて、その質問に戻りますが、jQueryはビジネスニーズを満たしていますが、MV *フレームワークを導入するために他に何が必要ですか？

これは製品タイプによって異なります。ページタイプの商品の場合、ほとんどの商品は必要ありません。ページ内のJavaScriptコードは、処理モデルよりもはるかに多くの対話を処理するためですが、それがアプリケーションソフトウェア製品である場合、これも必要です。

業界のソフトウェアに長い間取り組んできた企業は、一般に、主にデータモデル、ビジネスルール、およびビジネスプロセスでいくつかのビジネスコンポーネントを沈殿させます。これらのコンポーネントは基本的にバックエンドに存在し、フロントエンドに対応する組織はほとんどありません。過去の経験では、彼らはMVCを実行しましたが、いくつかのインターフェイスコンポーネントも実行しようとしましたが、JSFやGWTの使用など、慣例は時代遅れです。

JSFの問題は何ですか？問題は、インターフェイスがロジックと混在していることではありません。いわゆる垂直セグメンテーションコンポーネントであるPolymerの純粋なフロントエンドフレームワークも非常に分割されています。問題は、コンポーネントが同じ場所で生成およびレンダリングされないことです。したがって、ロジックコードの場所は非常に恥ずかしいものです。インターフェイスが単純な場合、それは非常に複雑です。これは明らかにフロントエンドのロジックコードですが、バックエンドを介して生成する必要があります。

このように、GWTは比較的優れています。問題は、UI調整の余地が小さすぎて、比較的柔軟性がないことです。

ある種のサーバー技術に基づくこの種のコンポーネント化には、いくつかの制限があります。たとえば、フロントエンドを大幅に制限します。初期のこの方法は良いかもしれませんが、時代の進展とともに、ユーザーはますますフロントエンドのユーザーエクスペリエンスが向上しており、フロントエンドに多くのエネルギーを戻す必要があります。 JSFやその他のソリューションのもう1つの問題は、ある種のサーバー環境にバインドされており、別の種類のバックエンドに切り替えることが難しいことです。 Hybird開発を使用する場合、一部のフロントエンドロジックを再利用することはほとんど不可能です。

それでは、純粋なフロントエンドフレームワークを見て、それらがどのように解決されるかを見てみましょう。例としてGoogleを取り上げます。ポリマーとアンギュラーの2つのフレームワークを立ち上げ、並行開発の段階にあります。 2つの概念にはまだ大きな違いがあり、多くの人に混乱をもたらしています。

コンポーネントをコンポーネントに分割する方法は、JSFにいくぶん似ています。これは、HTML5標準のShadowDOMおよびElementと多くの関係があります。コンポーネントを分割するこの方法は非常に直感的です。各コンポーネントはエンドツーエンドであり、UIとロジックを直接含みます。インターフェイスに配置することで使用できます。この方法はビジネス開発者に簡単に受け入れられますが、内部のタイミングを処理するのはより困難です。

たとえば、2つのコンポーネントがあり、それぞれにドロップダウンボックスがあり、データのリンケージ関係があります。これらは2つの異なるコンポーネントにあるため、コンポーネントの特性を考慮すると、リンケージ処理コードを記述しにくいです。独自の内部実装を非表示にして、コンポーネントの内部から要素を取得してレイヤーを一周し、コンポーネントが他の外部のものに依存できないようにするため、最終的には、達成するイベントを通じてのみ、このリンケージコードは次のようになります。配置すべき場所に配置することも大きな問題です。私たちの例はとても単純です。タイミングを確保するためには、このような大きな円を一周する必要があります。シーンが複雑な場合、制御が非常に困難になります。

同じコンポーネントがインターフェイスで複数回再利用される場合、データの一貫性を保証することは困難です。 1つのインターフェイスに2つの同一のドロップダウンボックスがあり、それらは異なるコンポーネントにあり、両方のデータを別々にロードする必要があると想像してください。このプロセスは無駄です。さらに、このドロップダウンボックスに対応するデータが更新されると、各インスタンスを更新することは困難です。このプロセスは非常に面倒です。

Angularフレームワークは問題を異なる方法で処理します。横に重ねられています。これらのデータアクセスロジックはすべてUIから完全に分離されているため、このロジックコードを記述するのは非常に簡単です。そのため、上記のコンポーネントは完全に劣化し、インターフェイスのみになります。

発生した2つの問題を見てください。まず、モデルコードはビジネスドメインに応じて分割されます。取得したデータは2つの異なる配列に配置され、双方向バインディングを介してUIに関連付けられます。 UIでドロップダウンボックスが選択されている場合。アイテムが変更された場合、この値アイテムを監視し、別のドロップダウンボックスの値リストを更新するだけで済みます。曲がる必要はありません。 2つのモデルが異なる場合でも、イベントバスなどのメカニズムを使用して、バックエンドと同様の方法で通信を完了することができます。

2番目は簡単です。再利用されるコンポーネントは、実際にはUIのみです。つまり、UIのみがマルチインスタンスです。モデルには、実際には1つのコピーしかありません。たとえば、1つのインターフェイスでメンテナンスと使用が行われている場合でも、リージョンのツリー構造です。両方の関数で同じモデルを共有できます。メンテナンス側でデータが更新されると、データはリアルタイムでモデルにフィードバックされ、双方向バインディングを使用して、インターフェイス上のユーザーにモデルが同期されます。全体のプロセスは明確です。コントロール。

コラボレーションの観点から、フロントエンド開発チームの多くのメンバーの責任はあまり明確ではありません。フロントエンドMV *フレームワークを使用すると、この状況は大幅に改善されます。 MV *フレームワークのアイデアは、その責任に応じてフロントエンドを階層化することです。各レイヤーは比較的独立しており、独自の価値があり、独自の開発の余地があります。

インターネットフロントエンド開発を行うほとんどの学生がMV *フレームワークの重要性を感じるのはなぜですか。このコラボレーションシステムでは、モデルが十分に複雑ではないためです。従来のソフトウェア分野では、モデル部分が最もコード化されており、ビューは相対的です。より少なく、インターネットの世界では、基本は反対であるため、モデルはマイナーな追加です。メインの操作がビューとコントローラーである場合は、もちろんjQueryのフレームワークの方が便利です。

そのため、インターネット製品を持っている学生はフロントエンドMVCについてよく話しますが、それらが例である場合、それらはとてつもないものです。多くの場合、彼らが引用しているモデルは実際には実際のモデルではなく、Viewを操作している最中です。いくつかの補助モデル、実際のモデルはフロントとリアを通ります。

結局のところ、フロントエンドMV *フレームワークは、ワークフローの変更のセット全体をもたらします。バックエンドエンジニアは、フロントエンドモデルコードを記述して、バックエンドで完全に開くこともできます。インタラクションエンジニアは、UIとモデル間のインタラクションを処理します。 UIスタッフは、HTMLソースコードに焦点を合わせて処理し、インターフェイステンプレートの形式でインタラクティブなエンジニアに提供できます。この一連の連携メカニズムは、B / Sアーキテクチャシステムの開発効率を大幅に向上させることができます。周辺機器の管理・制御プラットフォームがあれば、生産効率は真に工業化の段階に入ります。

この段階で、フロントエンド開発者にとってどのような方法がありますか？ 2種類あると思います。衣料産業を比較してみましょう。通常の場合は、大量生産に工業的手段を使用し、MV *フレームワークを使用し、アーキテクチャとコンポーネントの再利用をうまく行い、迅速に実行します。詳細はそれほど具体的ではありません。より良く、個性的になりたいのなら、デザイナー、手作り、非常に洗練された、ハイエンドな雰囲気が必要です。したがって、これはフロントエンド開発の2つの開発方向を表しています。

転載：https：//www.cnblogs.com/Blog-Yang/p/3385383.html