【プロジェクト実戦の典型例】 05. フロントエンドとバックエンドを分離するメリット（アンケート送付）

1. 背景

  次のフローチャートは、ユーザーにアンケートの質問を送信する全体的なプロセスであり、処理のためにフロントエンドに不要なビジネス ロジックが追加されます。これは論理的な混乱を招き、維持することが困難になります。フロントエンドとバックエンドを分離する目的の 1 つは、関数のスタイルをフロントエンドに配置し、関数のビジネス ロジックをバックエンドに配置して処理することです。

2、アイデア

  ビジネス ロジックを明確にする。UML 図を使用してビジネス ロジックを明確にし、整理し、マクロを理解することができます。百聞は一見に如かずです。フロントエンドの機能スタイルとそれに対応するバックエンドインターフェースを整理します。必要な計算と複雑な処理のビジネス ロジックをバックエンドに置き、データのレンダリングをフロントエンドに渡して直接表示します。メッセージを受信した後に複雑な計算ロジックを実行する必要はありません。

3. プロセス

1. 主なビジネスロジック

1. チャプター プッシュ ページで、実行された 3 つのチャプター パーティクルをクエリすると、バックエンド インターフェイスが呼び出され、ルールが Redis に保存されます。
2. チャプター パーティクル実行のカウントダウンが 10 に達すると、フロントエンドはバックエンド インターフェイスを呼び出してチャプター パーティクルのインセンティブ設定を取得し、それをフロントエンドに返します。
3. チャプター グラニュールが終了したら、アンケート送信を設定するかどうかを判断し、設定されている場合は、バックエンドのアンケート送信インターフェイスを呼び出してアンケートを送信し、次のチャプター グラニュールを実行する処理を続行します。設定がない場合は、プロセスを続行し、次の章を実行します。

2. 課題解決のアイデア

  1. バックエンドにタイマーを挿入します。このようにして、バックエンドが 10 秒までカウントダウンすると、インセンティブ ルールが呼び出され、タイマーが 0 秒に達するとアンケートが送信されます。このようにして、フロントエンドの論理判断を減らし、ロジックをバックエンドに置きます。そして入り口を減らします。

   2. 不要なループをキャンセルし、フローチャート上のループを削除します。呼び出す必要はありません。

4. まとめ

同じ関数のスタイルと論理計算を分解することで、
1. 開発効率が向上し、フロントエンドとバックエンドを担当者が開発できるようになります。
2. コードの保守性を強化し、スタイルとロジックの結合を減らします。問題を解決し、見つけやすくします。
3. 再利用性の向上と高い適応性 同じバックエンド プログラム コード セットを、変更することなく Web インターフェイス、携帯電話、タブレットなどのさまざまなクライアントで使用できます。
オブジェクト指向の考え方を体現しています。高い拡張性、高い再利用性、低いメンテナンスコスト。

五、オブジェクト指向の利点

1. モジュール性と保守性: オブジェクト指向プログラミングは、プログラムを複数の独立したオブジェクトに分割し、それぞれが独自のプロパティとメソッドを持ちます。このモジュール設計により、コードの保守性と拡張性が向上し、プログラム全体を変更しなくても、単一のオブジェクトを変更または置換するだけでプログラムの動作を変更できます。
2. カプセル化と情報の隠蔽: オブジェクト指向プログラミングでは、カプセル化を使用して、データと動作を自己完結型のオブジェクトに結合します。このオブジェクトは内部実装の詳細を外部から隠し、外部アクセス用に限定されたインターフェイスのみを提供します。この情報隠蔽メカニズムにより、データの整合性とセキュリティが保護され、コードの再利用性が向上します。
3. 継承とコードの再利用: オブジェクト指向プログラミングでは継承メカニズムがサポートされており、既存のクラスを継承して新しいクラスを作成したり、親クラスのプロパティやメソッドを再利用したりできます。このコード再利用メカニズムにより、繰り返しコードを記述する作業負荷が軽減され、コードの保守性と拡張性が向上します。
4. ポリモーフィズムと柔軟性: オブジェクト指向プログラミングはポリモーフィズムをサポートしています。つまり、同じメソッドが異なるオブジェクト呼び出しに応じて異なる動作を示すことができます。この柔軟性により、プログラムは実際の状況に応じて動的に適応および拡張できるため、コードの柔軟性と拡張性が向上します。
5. 抽象化モデルと概念モデル: オブジェクト指向プログラミングでは、抽象化を使用して、現実世界の概念とエンティティをプログラム内のクラスとオブジェクトに変換します。この抽象化プロセスにより、プログラムが問題領域の概念モデルに近づき、プログラムの読みやすさと理解しやすさが向上します。

6. フロントエンドとバックエンドの分離をどのように実現するか

フロントエンドとバックエンドを分離するには、次の手順が必要です。

1. フロントエンドとバックエンドを分離するためのアーキテクチャとテクノロジー スタックを決定します。一般的に使用されるアーキテクチャには、RESTful API、マイクロサービス アーキテクチャなどに基づくフロントエンドとバックエンドの分離が含まれます。テクノロジー スタックには、フロントエンド フレームワーク、バックエンド フレームワーク、データベースなどが含まれます。
2. フロントエンドとバックエンドは、データ対話のためのインターフェース仕様とデータ形式 (JSON など) をネゴシエートします。
3. バックエンド開発では仕様に基づいた API サービスを提供し、フロントエンド開発では API 呼び出しデータに基づいてページ表示やインタラクションを実装します。
4. フロントエンドとバックエンドの開発が分離されており、Git をバージョン管理に使用でき、フロントエンドとバックエンドを独立して開発およびテストできます。
5. フロントエンドとバックエンドは独立してデプロイおよびリリースされ、コンテナ化テクノロジー (Docker など) を使用してデプロイメント環境を統合できます。

つまり、フロントエンドとバックエンドの分離の核心は、フロントエンドとバックエンドの開発とデプロイメントを分離し、API インターフェイスを介したデータ対話を実現することで、開発効率とコードの保守性が大幅に向上します。

7、フロントエンド分離のメリット

1. 開発効率の向上: フロントエンドとバックエンドの分離により、フロントエンドとバックエンドのチームが独立して開発できるようになり、開発効率が向上します。

2. メンテナンスの改善: フロントエンドとバックエンドの分離により、フロントエンド UI がバックエンド ビジネス ロジックから分離され、バックエンドはフロントエンド UI の変更を考慮する必要がなくなり、実装のみに集中する必要があります。バックエンドのビジネス ロジックのメンテナンスが可能になり、メンテナンスの複雑さが軽減されます。

3. ユーザー エクスペリエンスの向上: フロントエンドとバックエンドの分離により、フロントエンドで既存のフロントエンド フレームワークとテクノロジを採用できるようになり、フロントエンド開発の自由度と柔軟性が向上し、ユーザー エクスペリエンスが向上します。

4. クロスプラットフォームのサポート: フロントエンドとバックエンドの分離により、フロントエンド開発で複数のテクノロジーを採用し、複数の端末とプラットフォームをサポートし、より良いユーザー エクスペリエンスを提供できます。

5. システムの安定性とセキュリティの向上: フロント エンドとバック エンドの分離により、フロント エンドをクライアント側で実行できるようになり、バックエンド サービスの独立性が高まり、システムの安定性とセキュリティが向上します。