なぜフロントエンドとバックエンドを別々に記述する必要があるのでしょうか?

ご存知のとおり、企業は通常、フロントエンドとバックエンドを別々に記述することを要求します。なぜこれを行うのでしょうか?今回はなぜフロントエンドとバックエンドを分けて書く必要があるのか​​をお話します。以下は実際のケースです。

フロントエンドとバックエンドの分離のワークフローを試したことがない場合は、まず次のようにプロセスを変更してみてください:
PM:「この機能が欲しい」からプロセスを変更します。
バックエンド:「最初」テンプレートを作成するためのフロントエンドを見つけます
フロントエンド: 「テンプレートが完成しました」
バックエンド: 「接続しましょう、ここのスタイルは間違っています」
フロントエンド: 「修正が完了しました」
バックエンド: 「関数の配信」
PM: 「このアクティビティは春節中に追加されます」
バックエンド: 「まずテンプレートを変更するフロントエンドを見つけましょう」
フロントエンド: 「テンプレートは次のとおりです」完了しました」
バックエンド: 「接続させてください、ここのスタイルは間違っています」
フロントエンド: 「変更が完了しました」
バックエンド: 「機能提供」

が

PM: 「欲しいこの機能です」

フロントエンド:「インターフェースが欲しい」
バックエンド:「インターフェースが完成しました」
フロントエンド:「接続して機能を納品させてください」
PM:「中に追加したい」このアクティビティは「
フロントエンド:「インターフェースを追加する必要があります」
バックエンド:「インターフェースが完成しました」
フロントエンド:「接続して機能を提供します」

ということができますフロントエンドとバックエンドの分離の主な概念は次のとおりです。バックグラウンドは API インターフェイスを提供するだけでよく、フロントエンドは AJAX を呼び出してデータ プレゼンテーションを実現します。

現状と相違点

フロントエンド開発者として、私たちはいくつかの新しいテクノロジーを試し、あらゆる細部の問題を改善し、常に自分自身を突破する必要があります。フロントエンドとバックエンドの分離は新しいテクノロジーやアイデアではありませんが、多くのバックエンド開発者、さらにはフロントエンド開発者さえもその分離に慣れていません。

私の個人的な理解によれば、ある部門のすべての担当者がバックエンド開発者であり、一部のフロントエンド ページもバックエンド担当者によって完成されている場合、フロントエンドとバックエンドの分離は可能性があります。彼らにとっては未知の分野であり、ほとんどのプロジェクトではフロントエンドとバックエンドは強く結びついており、フロントエンドという概念すら存在しません。

フロントエンドに注意を払わない会社や部門では、フロントエンドとバックエンドの分離を理解していないのは当然です。ほとんどの起業家企業には各部門に 1 つまたは 2 つのフロントエンド部門があり、1 人が複数のプロジェクトを担当することが多く、協力してプロジェクトを完了することはほとんどありません。標準がまったくないため (ここでの標準とはコード構成構造を指します)、フロントエンドのスタッフが画像を切り取り、ページを作成してバックエンドにスローし、バックエンドのコード構造が次のように使用されます。標準。フロントエンドとバックエンドの分離の意識はあっても、どのように実践すればよいのかわからない企業もあります。当時、バックエンド部門の担当者は、フロントエンドとバックエンドを分離することで、バックエンドは HTML や JS を書く必要がなくなり、フロントエンドに任せることができると考えていました。これはフロントエンドとバックエンドの分業としか言えません。

上記は、フロントエンドとバックエンドの分離を理解しておらず、それを実践する方法もわからないという状況を説明しています。以下に別の状況があります。フロントエンドとバックエンドの分離は理解しているが、試したくない場合です。

2 番目の状況に対して、多くの人が同様の説明をしています。実際、これには「フロントエンドとバックエンドの分離の是非」の問題が関係しています。多くのバックエンド担当者は、バックエンドがフロントエンド HTML を適用しても問題ないと考えるでしょう。バックエンド MVC フレームワークもこのように推奨されています。とても合理的です。現時点では、フロントエンド開発者は部門内で十分な発言権を持っていないか、バックエンド開発者の意見が常に正しく主観性がないと考えていることがよくあります。

逆に、バックエンド開発者はフロントエンドとバックエンドの分離を強く推奨しているのに、フロントエンド開発者はそれを実践したくないのかもしれません。このとき、フロントエンドはバックエンドの開発者がイタズラしていると考えてしまいます。これまではフロントエンドとバックエンドを分けずにプロジェクトを進めていましたが、端が分離されていると、追加の作業負荷と学習コストが発生しますが、これは技術的な能力と認識に依存します。

もちろん、これは私が個人的にフロントエンドとバックエンドの分離の現状と違いがあると思うところでもあります。

シナリオと要件

すべてのシナリオがフロントエンドとバックエンドが分離されているアプリケーション シナリオに適しているわけではありませんが、ほとんどのプロジェクトはフロントエンドとバックエンドの分離によって実現できます。

私は主にエンタープライズレベルのバックエンドアプリケーションのフロントエンド開発に従事しているため、バックエンドアプリケーションの開発においては、フロントエンドとバックエンドの分離のメリットがデメリットをはるかに上回っていると個人的に考えています。

ほとんどのバックグラウンド アプリケーションを SPA アプリケーション (シングルページ アプリケーション) にできます。シングルページ アプリケーションの主な機能は、フロントエンド コントロール ルーティングを通じて AJAX を呼び出し、インターフェイスを提供することで実現できます。この方法により、ユーザー エクスペリエンスがよりフレンドリーになり、Web ページの読み込みが速くなり、開発とメンテナンスのコストが大幅に削減され、効率が大幅に向上しました。

同様に、表示WebサイトやモバイルAPPページのフロントエンドとバックエンドの分離も試みられています。フロントエンドとバックエンドが分離されていない場合、サーバーは Web 側を個別に処理して完全な HTML を返す必要があり、必然的にサーバーの複雑さが増し、Web 側で完全な HTML を読み込む必要があり、パフォーマンスに影響します。これは、モバイルのパフォーマンスが重要な場所にとっては非常に不親切です。

フロントエンド テクノロジーの開発と反復により、フロントエンド MVC フレームワークが誕生しました。React、Vue、Angular などの現在の主流のフロントエンド フレームワークを使用して、次のような Web サイトを簡単に構築できます。同時に、このクラス フレームワークはすべて、フロントエンド ルーティング機能 を提供し、ルーティング ジャンプを制御できなくなり、元々フロントエンドに属していたすべてのビジネス ロジックをフロントエンドにスローします。 -end これは、フロントエンドとバックエンドの最も完全な分離であると言えます。以下はフロントエンド制御ルーティングのコードです:

'use strict'export default function (router) {
    router.map({        '/': {            component: function (resolve) {                require(['./PC.vue'], resolve)
            }
        },        '/m/:params': {            component: function (resolve) {                require(['./Mobile.vue'], resolve)
            }
        },        '/p': {            component: function (resolve) {                require(['./PC.vue'], resolve)
            },            subRoutes: {                '/process/:username': {                    component: function (resolve) {                        require(['./components/Process.vue'], resolve)
                    }
                }
            }
        }
    })
}

フロントエンドとバックエンドの分離の実装により、技術担当者、特にフロントエンド担当者の要件が高まります。フロントエンドの作業は単なるものではありません。ページの切り取りやテンプレートの作成、または単純な JS ロジックの処理について、フロントエンドではサーバーから返されるさまざまなデータ形式を処理する必要があり、一連のデータ処理ロジック、MVC のアイデア、およびさまざまな主流フレームワークを習得する必要もあります。

メリットと意義

フロントエンドとバックエンドの分離の意味はフロントエンドレンダリングの意味と考えることもできますが、主に以下の4点をまとめました:

フロントエンドを完全に解放する
フロントエンドは、バックエンドまたはバックエンドにテンプレートを提供する必要がなくなりました。バックエンド コードは、次のようにフロントエンド HTML に埋め込まれます。これは、フロントエンドとバックエンドの間に結合されており、可読性が低くなります。

<!--服务器端渲染 --><select>
    <option value=&#39;&#39;>--请选择所属业务--</option>
    {% for p in p_list %}    <option value="{{ p }}">{{ p }}</option>
    {% endfor %}</select>

上記はフロントエンド レンダリングのコードです。フロントエンドは AJAX を介してバックエンド インターフェイスを呼び出します。データ ロジックはフロントエンドに配置され、フロントエンドによって維持されます。

作業効率の向上と分業の明確化

フロントエンドとバックエンドを分離するワークフローにより、フロントエンドはフロントエンドの事項のみに集中し、バックエンドはバックエンドの活動のみを考慮することができます2 つの開発は同時に実行できます。バックエンドがインターフェイスを提供する時間がない場合は、最初にデータを書き込むか、ローカルの JSON ファイルを呼び出す必要はありません。ページの追加やルートの変更時にバックエンドに煩わされることがなくなり、開発がより柔軟になります。

部分的なパフォーマンスの向上

フロントエンドルーティングの設定により、ホームページがロードされるとすぐに、Web サイトのすべてのリソースをロードする必要がなくなりました。フロントエンド ページを解析することで、ページの操作性とユーザー エクスペリエンスが向上しました。

メンテナンスコストの削減

現在主流のフロントエンド MVC フレームワークにより、クライアント側の問題を非常に迅速に特定して発見できるようになり、バックエンド担当者の参加や

デバッグ
、コードのリファクタリング、保守性の強化が必要なくなりました。 考察と洞察:

その過程で、最初のバックグラウンド コントロール ルーティングとバックグラウンド レンダリング ページから、現在のフロントエンド コントロール ルーティングとフロントエンド レンダリング データに至るまで、プロジェクトが次々に変更され、ワー​​クフローとメソッドが変更されました。大きな変化。次のような状況に遭遇するたびに、フロントエンドとバックエンドの分離によってもたらされるメリットに感動してため息をつきます。

1. プロジェクトの最初にフロントエンド ページを作成するときに、もう必要ありません。サーバー

環境を設定するためのバックエンド

2. バックエンド インターフェイスを呼び出す必要があるときに、プロジェクトのフロントエンド ファイルをサーバーに投入することができます。プロジェクト ページを追加してルーティングを設定する必要がある場合、バックエンドの同僚に追加を依頼する必要がなくなり、フロントエンドで自分で行うことができます4. フロントエンド ファイルがバックエンド コードと混合されなくなりました。ロジックが改善され、かなり快適になりました5. ページのジャンプが以前よりスムーズになり、部分的なレンダリングと部分的な読み込みが非常に高速になりました
6. ページ テンプレートを使用すると、フロントエンド コンポーネントの開発効率が向上します

すぐ。フロントエンドの急速な発展に直面して、フロントエンドとバックエンドの分離という現在の作業方法は、それによってもたらされる作業方法とプロセスの変化に適応する必要があります。 -エンド開発者は、新しいフロントエンドを普及させる責任があり、変化をもたらす責任があります。

この記事の事例を読んだ後は、この方法を習得したと思います。さらに興味深い情報については、php 中国語 Web サイトの他の関連記事に注目してください。

関連書籍:

Angularjs で mvvm スタイルのタブを実装するには? Case + code

vue2.0プロジェクトの非常に実用的なコード集

以上がなぜフロントエンドとバックエンドを別々に記述する必要があるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。