Vueシリーズ3：前面と背面の分離の進化

なぜ前後に分離する必要があるのですか

3.1。バックエンドベースのMVC時代

開発の複雑さを軽減するために、バックエンドが出発点になります。たとえば、Struts、Spring MVC、およびその他のフレームワークの使用はバックエンドMVCの時代であり、プロセスを例として
取り上げます。SpringMVC

フロントコントローラーへのリクエストを開始します（Dispatcher Servlet）
フロントエンドコントローラーはHandlerMapping検索を要求します。検索は、構成と注釈Handlerに従って検索できます。xml
ハンドラーマッパーHandlerMappingがフロントコントローラーに戻りますHandler
フロントコントローラーはハンドラーアダプターを呼び出して実行しますHandler
実行するプロセッサアダプタHandler
Handler実行が完了したらアダプタに戻りますModelAndView
ハンドラーアダプターはフロントコントローラーModelAndViewに戻り、フレームワークの低レベルオブジェクトであり、ModelAndViewSpringMvcModelView
フロントエンドコントローラーは、ビューパーサーにビューの解析を実行するように要求し、論理ビュー名（JSP）に従って実際のビューに解析します。
ビューリゾルバーがフロントコントローラーに戻りますView
フロントコントローラーがビューレンダリングを実行し、ビューレンダリングModelAndViewがモデルデータ（オブジェクト内）をrequestフィールドに入力します
フロントエンドコントローラーはユーザーの結果に応答します。利点MVCは非常に優れた協調パターンであり、コードの結合を効果的に減らすことができます。アーキテクチャから、開発者はコードをどこに書くべきかを理解できます。ビューをより純粋にするために、タイムリーフ、フリーマーカーなどのテンプレートエンジンを使用することもできます。これにより、Javaコードをテンプレートに記述できなくなり、フロントエンドとバックエンドの分業がより明確になります。。欠点
フロントエンド開発は開発環境に大きく依存しており、開発効率が低くなっています。このアーキテクチャでは、フロントエンドとバックエンドのコラボレーションには次の2つのモードがあります。
- 1つ目は、フロントエンドにDEMOを記述し、それを記述した後、バックエンドをテンプレートに移動させることです。利点は、DEMOをローカルで開発できることです。これは非常に効率的です。欠点は、バックエンドテンプレートがまだ必要であり、間違っている可能性があることです。セットが完了した後、フロントエンドを決定する必要があり、前後の通信と調整のコストが比較的高くなります。
- もう1つのコラボレーションモードは、フロントエンドがすべてのブラウザー側の開発とサーバー側のビューレイヤーテンプレートの開発を担当することです。利点は、すべてのUI関連のコードがフロントエンドで記述され、バックエンドをあまり気にする必要がないことです。欠点は、フロントエンドの開発がバックエンド環境に強く拘束されていることです。環境は、フロントエンド開発の効率に影響を与える重要な要素になります。
フロントエンドとバックエンドの責任は絡み合っています。テンプレートエンジンは強力であり、取得したコンテキスト変数を介してさまざまなビジネスロジックを実装できます。このように、フロントエンドが弱い限り、バックエンドはテンプレートレイヤーに多くのビジネスコードを記述する必要があることがよくあります。コントローラーには大きな灰色の領域もあります。ページルーティングなどの機能はフロントエンドについて最も懸念している。バックエンドによって実装されている。コントローラー自体とモデルが絡み合っていることが多く、人々に歯を食いしばらせるビジネスコードがコントローラーレイヤーに表示されることがよくあります。これらの問題は、プログラマーの品質に起因するものではありません。そうでない場合は、JSPで十分です。
フロントエンドの制限：パフォーマンスの最適化がフロントエンドでのみ行われる場合、スペースが非常に限られているため、バックエンドの協力が必要になることがよくありますが、バックエンドフレームワークの制限により、 [Comet]、[BigPipe]などの技術ソリューションを使用してパフォーマンスを最適化します。
注：初期のJSPを含むこの期間（2005年以前）では、PHPはWeb1.0の時代と呼ぶことができます。ここで言いたいのは、Javaの初心者の場合、JSPなどの古いテクノロジーを真剣に受け止めないでください。時代は変化し、テクノロジーは変化し、すべてが変化しているからです（Zuckerberg Gridの文章を引用：唯一の定数変化そのものです）大学に行って実習をするとき、乾物については何も言えないと思う学生もいますが、そうではなく、あなたの認識では乾物としか言えません。市場にとって重要です。すでに延滞していると言いました

3.2.AJAXに基づくSPAの時代

2005年に、A OAX（非同期JavaScriptとXML、非同期JavaScriptとXML、古いテクノロジーの新しい使用法）が正式に提案され、静的リソースストレージとしてCDNの使用が開始されたため、JavaScriptの王様が戻ってきました（その前はJSウェブページに犬の皮の石膏の広告を掲載したSPA（シングルページアプリケーション）のSPA（シングルページアプリケーション）時代に使用されました。

利点
このモードでは、フロントエンドとバックエンドの間の分業が非常に明確であり、フロントエンドとバックエンドの間の重要なコラボレーションポイントはAJAXインターフェイスです。**見た目はとても良いですが、振り返ってみると、JSPの時代と大差ありません。複雑さはサーバー側のJSPからブラウザーのJavaScriptに移り、ブラウザー側は非常に複雑になります。Spring MVCと同様に 、ブラウザー側の階層化アーキテクチャーがこの時代に登場し始めました。

短所

フロントエンドとバックエンドのインターフェースの規則：バックエンドのインターフェースが混乱していて、バックエンドのビジネスモデルが十分に安定していない場合、フロントエンドの開発は非常に苦痛になります。多くのチームも同様の方法を試しました。インターフェイスルールやインターフェイスプラットフォームなど。バックエンドで作成されたインターフェイスルールを使用して、データのシミュレーションにも使用できるため、インターフェイスが合意された後、フロントエンドとバックエンドで効率的な並列開発を実現できます。
フロントエンド開発の複雑さの制御：SPAアプリケーションはほとんど機能的でインタラクティブであり、JavaScriptコードが100,000行を超えるのは通常のことです。大量のJSコードの編成、ビューレイヤーとのバインドなどは簡単なことではありません。

3.3。フロントエンドベースのMV*時代

ここでのMV*パターンは次のとおりです。

MVC（主に同期通信）：モデル、ビュー、コントローラー
MVP（主に非同期通信）：モデル、ビュー、プレゼンター
MVVM（主に非同期通信）：フロントエンド開発の複雑さを軽減するために、Model、View 、およびView Modelは、、、、などAngular JSの多数のフロントエンドフレームワークを生み出しました。これらの一般原則フレームワークは、以下に示すように、最初にテンプレート、コントローラー、モデルなどのタイプごとにレイヤー化し、次にレイヤーでセグメンテーションを行います。ReactVue.jsEmber JS

アドバンテージ

フロントエンドとバックエンドの責任は非常に明確です。フロントエンドはブラウザ側で機能し、バックエンドはサーバー側で機能します。明確な分業により、並行開発、簡単なテストデータシミュレーション、およびフロントエンドのローカル開発が可能になります。バックエンドは、RESTfulなどのビジネスロジックおよび出力インターフェイスの処理に集中できます。
フロントエンド開発の複雑さは制御可能です。フロントエンドコードは非常に重いですが、フロントエンドコードがその役割を実行できるように、適度に階層化されています。この作品は非常に興味深いもので、テンプレート機能の選択と同じくらい単純で、多くの詳細があります。より強力であるほど、どのような制限があり、どのような自由が残されているか、コードをどのように編成するか、これらすべての設計を本の厚さで説明する必要があるというわけではありません。
比較的独立した展開：製品エクスペリエンスを迅速に改善できる短所
コードは再利用できません。たとえば、バックエンドは引き続きデータに対してさまざまな検証を実行する必要があり、検証ロジックはブラウザ側でコードを再利用できません。再利用できれば、バックエンドのデータ検証を比較的簡単に行うことができます。
完全に非同期で、SEOに悪い。多くの場合、サーバー側も同期レンダリングのダウングレードソリューションを実行する必要があります。
特にモバイルインターネット環境では、パフォーマンスは最適ではありません。
SPAはすべてのニーズを満たすことはできませんが、マルチページアプリケーションはまだ多数あります。URL設計にはバックエンドの連携が必要であり、フロントエンドを完全に制御することはできません。

3.4.ノードJSによってもたらされたフルスタックの時代

フロントエンドベースのMV*モデルは多くの問題を解決しますが、前述のように、まだ多くの欠点があります。Node JSの台頭により、JavaScriptはサーバー側で実行できるようになりました。これは、新しいR＆Dモデルが存在する可能性があることを意味します。

このR＆Dモデルでは、フロントエンドとバックエンドの責任が明確になっています。フロントエンドの場合、2つのUIレイヤーが独自の役割を果たします。

フロントエンドUlレイヤーは、ブラウザーレイヤーのプレゼンテーションロジックを処理します。アプリケーションのシナリオに応じて、CSSを介したスタイルのレンダリング、JavaScriptを介したインタラクティブ機能の追加、およびHTML生成もこのレイヤーに配置できます。
バックエンドUlレイヤーは、ルーティング、テンプレート、データフェッチ、Cookieなどを処理します。ルーティングを通じて、フロントエンドは最終的にURLデザインを独立して制御できるため、フロントエンドはシングルページアプリケーションかマルチページアプリケーションかを自由に制御できます。バックエンドは最終的にプレゼンテーションへの強い焦点を取り除くことができ、代わりにビジネスロジック層の開発に集中することができます。
Nodeを介して、WebServerレイヤーもJavaScriptコードです。つまり、一部のコードは前後に再利用でき、SEOを必要とするシーンはサーバー側で同期的にレンダリングできます。非同期リクエストが多すぎるために発生するパフォーマンスの問題も、次の方法で軽減できます。サーバー側。前者のモデルの欠点は、このモデルによってほぼ完全に解決できます。
JSPモデルと比較すると、フルスタックモデルは回帰のように見え、実際には元の開発モデルに戻りますが、スパイラルアップに戻ります。
Node JSに基づくフルスタックモードは、依然として多くの課題に直面しています。
フロントエンドは、サーバー側のプログラミングをさらに理解する必要があります。TCP/IPなどのネットワーク知識の習得など。
NodeJSレイヤーとJavaレイヤー間の効率的な通信。ノードJSモードでは、すべてサーバー側にあり、RESTful HTTP通信は効率的ではない可能性があり、SOAPやその他の方法による通信はより効率的です。検証ではすべてを進める必要があります。
部門と運用および保守レベルを十分に理解するには、より多くの知識ポイントと実践的な経験が必要です。
多数の歴史的問題を移行する方法。これはおそらく最大の抵抗です。
注：これを見た後、私がクラスでいつも言う理由を多くの学生が理解できると思います。「フロントエンドはバックエンドを学ぶのは難しいですが、バックエンドプログラマーは何でも学ぶのは簡単です」 ;それは私たちバックエンドプログラマーが比較的完全な知識システムを持っているからです。
フルスタック！とても簡単！

3.5.まとめ

要約すると、モードが良いか技術が良いかに関係なく、良いか悪いかはなく、適切かどうかだけです;フロントとリアの分離の開発アイデアは主にSoc（分離の原理懸念事項）、および上記のモードは、前面と背面のより明確で効率的な分業の責任です。