1. フロントエンドとバックエンドのコラボレーションには主に 2 つのタイプがあります。1 つはバックエンドの書き込みインターフェイス、フロントエンドは artTemplate または vue.js を使用してデータをレンダリングするもの、そしてフロントエンドとバックエンドは-end は分離されています;
2. もう 1 つは、プロジェクトが PHP の Smarty や Java の FreeMarker などのバックエンド テンプレート エンジンを使用していることです。フロントエンドとバックエンドが分離されている場合、バックエンドが責任を負います。ドキュメントの作成や機能の実行には、フロントエンドがバックエンドのテンプレート エンジンの使用法を学習し、動的環境で変更を加える必要があります。
3. 主に 2 番目のタイプ 向けです。以前は、バックエンドが常にページの設定を担当していました。フロントエンドから送信されたページに問題が発生することがありました。その結果、フロントエンドは依然としてページを組み立てる必要がありました。アップグレードすると、フロントエンドとバックエンドの共同デバッグのコストが比較的高くなります#4。フロントエンドを実行させるのはさらに面倒でしょうか?バックエンド テンプレート エンジンと今統合したいのですが? 御社におけるフロントエンドとバックエンドのコラボレーションはどのようなものなのかお聞きしたいのですが?または、より良いコラボレーション方法
当社は比較的シンプルかつ簡単で、2番目のオプションを採用します。
PHP フレームワークが使用されます。フロントエンドはページを記述するだけで、その後バックエンド ロジックが処理されます。ページなどを設定するために
框架语法
或者php语法
を使用する必要がある場合は、バックエンド スタッフにレンダリング ページを出力させます (一部の JS はバックエンドでも記述され、フロントエンドは静的ページを記述するだけで済みます)。フロントエンド ページは問題なく作成でき、バックエンド ページは一般的にかなり高速です。バックエンド スタッフがビュー データのレンダリング時にスタイルに問題を発見した場合、問題システムに問題を送信します (はい、問題システム プロジェクトがあります。これは内部使用に限定されており、フロントエンドとバックエンドで使用されます) -エンド担当者がバグを提出する)、フロントエンドおよびバックエンド担当者全員がエンド開発者自身の問題システムに問題がないかを毎日チェックし、解決します。
実際、ルールが設定され、すべてがルールに従っている限り、フロントエンドとバックエンド間の協力は便利かつ明確になります。
実際のフロントエンドとバックエンドは、インターフェースデータを取得してそれを走査するために JS である必要があります。ページが変更された場合、それもフロントエンドのものでなければなりません
。1 つ目は、MVVM モードを実装することです。これは、フロントエンドとバックエンドの分離を意味し、フロントエンドがページをレンダリングするためにバックグラウンド フレームワークやバックグラウンド メソッドを習得する必要がないことです。ページから完全に分離できるため、メンテナンスが容易になります。さらに、バックエンド API インターフェイスはより多くのプラットフォームで使用でき、二次開発は必要ありません。欠点は、ページがホームページの場合、データを取得してレンダリングするために多くの API が必要になることです。しかし、MVC アーキテクチャの方がはるかに便利です
MVC を実装する 2 番目の方法は、バックエンドがロジックの設定を担当し、フロントエンドがページのレンダリングを担当しますが、フロントエンドは MVC バックエンド開発のテンプレートをある程度理解している必要があります個人的には、これによりバックエンドがより便利になり、フロントエンドがより困難になると思います。
3回目の説明。
実際には、別の種類のフロントエンド作業とバックエンド作業があります。もちろん、これはプロジェクトに広く適用できるものではありません。たとえば、NODE.JS
は実際には主に会社のフロントエンドとバックエンドの構成とプロジェクトに依存します。たとえば、バックエンドに 1 つ多くの B があり、フロントエンドが 1 つ少ない当社のような企業は、MVC アーキテクチャを使用することができ、フロントエンドのレンダリングはバックエンドによって処理されます。もちろん、フロントエンド担当者が多い場合は、MVVM モデルの方が断然適しています。もちろん、これは単なる表面的な問題です
これは単に人間の問題のようです、何も悪いことはないと思います
弊社では、ご指摘の2種類の両方を使用しております。最初のページに関して、あなたの会社は Java または PHP プロジェクトからフロントエンド ページを取り出したのでしょうか、それともまだそれらの中にネストされているのでしょうか? Java または PHP プロジェクトにネストされている場合は、バックエンドのテンプレート エンジンにフロントエンドを埋め込んでおけば問題はありません。当社のバックエンド プロジェクトはすべて Java プロジェクトにネストされており、個別に移動することはありません。 . フロントエンドをよく使う バックエンドのテンプレートエンジンの書き方は問題ありません。 2 番目のタイプについては、共同デバッグのコストは比較的高くないと思いますが、どのような状況で共同デバッグがより面倒になるかはわかりません。
静的なものを与えて、自分で ajax をプレイできるようにします
元の投稿者と同じ、混合開発、問題はたくさんありますが、後からやらないとどうしようもありません。
国内企業の多くはプロフェッショナルではありません、それについて私たちにできることは何もありません、全体的な環境はこのようなものです、私たちは最善を尽くすしかありませんフロントエンドとバックエンドを分離する方法はたくさんあります。もちろん、フロントエンドとバックエンドが混在しないように純粋なインターフェイスで接続することが最も理想的です。
しかし現実はそうではありません。たとえば、会社に既存のバックエンドとフロントエンドがある場合、ページを調整できるのはバックエンド コードのみです。
私たちの解決策は、バックエンドによるページの移動を停止することです。
利点は次のとおりです
1. ページのフロントエンドの制御が独占的です
2. フロントエンドとバックエンドの責任が分離されています
欠点は次のとおりです
1. デバッグが不便です
3. 多くのフロントエンドスキャフォールディングは使用できません
分離はなく、フロントエンドは静的ページのみを設計し、バックエンドが統合を担当します
または、フロントエンドとバックエンドが完全に分離され、バックエンドが API を作成するかのどちらかだと思います。 、フロントエンドは jquery ajax、react、または vue を使用してこれらの API を呼び出し、ページはフロントエンドによって完全に書き込まれます。
完全に分離する場合、バックエンドは標準化されたインターフェイスを記述する必要があり、各インターフェイスは明確なドキュメント (正常なフローによって返されるデータ インスタンスと異常なフローのデータ インスタンス! 主に戻り値の階層構造と変数の名前付け) を提供する必要があります。 )、これらのデータを使用するフロントエンド開発を容易にするため)、インターフェイスが変更されたときは、ドキュメントを適時に更新する必要があり、フロントエンド開発者に通知することが最善です。そうしないと表と裏の連携がめちゃくちゃになってしまいますよ! !
インターフェイスドキュメントはバックグラウンドで提供されます。フロントエンドが静的ページを書き込むとき、インターフェイスドキュメントに従って偽のデータを模擬することができます。最後に、インターフェイスが作成されるまで待機して模擬操作をキャンセルします。
最初のタイプでは、フロントエンドに多くの要件があります。ページデータは API インターフェイス間の接続を通じてレンダリングされ、バックエンドはインターフェイスを提供するだけで済みます。このようにして、役割分担がより明確になり、各ポジションは得意なことだけを行う必要があります。
2 番目のタイプでは、さらに多くのバックエンドが必要です。フロントエンドは静的テンプレート ページを提供するだけでよく、バックエンドはテンプレート フレームワークを介してデータをレンダリングします。また、必要な効果の一部を実現するには、いくつかの ajax と Js を使用して記述する必要があります。問題が発生した場合、フロントエンドとバックエンドの共同デバッグが必要になります。