パート 2. ソフトウェア アーキテクチャについて少し話しましょう

この資料は「エンタープライズ開発入門」シリーズの一部です。ネットワークに関する最初の部分はここにあります。 ソフトウェア アーキテクチャは、アプリケーションの作成に基づいて、プログラム全体のモジュールとコンポーネントが相互作用する構造です。プログラマは長い間、優れたアーキテクチャを作成しようとしてきました。そのため、現在では多くのアーキテクチャ パターンを知っていることは驚くべきことではありません。これらを理解する必要があります。Web アプリケーションを作成する場合、通常のアプリケーションよりも多くのコンポーネントとモジュールが含まれるため、アーキテクチャの問題が深刻になります。 アーキテクチャ パターンは、ソフトウェア設計の問題を解決するためにすでに考えられている方法です。おそらく、ファクトリ メソッド、抽象ファクトリ、ビルダー、プロトタイプ、シングルトンなどのデザイン パターンをすでに目にしたことがあるでしょう。これらは、単にコードを記述し、クラスを作成し、それらがどのように相互作用するかを計画するために使用されます。アーキテクチャ パターンは、アプリケーション ユーザーとサーバー、データ、およびプロジェクトのその他のコンポーネントとの対話を計画するときに、より高い抽象レベルで使用されます。いくつかのテンプレートとその使用方法を簡単に見てみましょう。

クライアントサーバーアーキテクチャ

名前から、このトピックに関するすべてが単純かつ明確であるという印象を受けます。ただし、条件付きスプリングの学習を開始するときに、私たちが何について話しているのかを正確に理解できるように、いくつかの点を明確にしましょう。あなたがチャットを作成し、あなたとあなたの友人がそれを使い始めたとしましょう。ここでは簡単なオプションが可能です。あなたが知っている IP アドレスを使用して、インターネット経由でメッセージを直接お互いに送信します。 最初はすべてがうまくいっているように見えますが、別の友人が次のような質問をしてくるまでは、私をチャットに追加してくれませんか？」そして、共通の友人をチャットに追加することにした場合、アーキテクチャ上の問題に直面します。各チャット ユーザーは、ユーザー数に関する情報を更新し、新しいユーザーの IP アドレスを追加する必要があります。また、メッセージを送信する場合は、参加者全員にメッセージが届く必要があります。これらは、発生するであろう最も明白な問題です。コード自体にはさらに多くの問題が隠されているでしょう。これらを回避するには、ユーザーに関するすべての情報を保存し、ユーザーのアドレスを知っているサーバーを使用する必要があります。メッセージはサーバーに送信するだけで済みます。そして、今度はすべての受信者にメッセージを送信します。チャットにサーバー側を追加すると決めたら、クライアント/サーバー アーキテクチャの構築を開始します。

クライアントサーバーアーキテクチャのコンポーネント

彼女が何者なのか調べてみましょう。 クライアント/サーバー アーキテクチャは、Web アプリケーション作成の基礎となる設計パターンです。このアーキテクチャは、次の 3 つのコンポーネントで構成されます。

1. クライアント - 名前から、これがサーバーに接続して情報を取得するサービス (Web アプリケーション) のユーザーであることがわかります。

2. サーバーは、Web アプリケーションまたはそのサーバー部分が配置される場所です。彼はユーザーに関する必要な情報を所有しているか、それを要求することができます。また、クライアントが接続すると、サーバーは要求された情報を返します。

3. ネットワークはシンプルです。クライアントとサーバーの間で情報が確実に交換されます。

サーバーは、さまざまなユーザーからの膨大な数のリクエストを処理できます。つまり、多数のクライアントが存在する可能性があり、相互に情報を交換する必要がある場合は、サーバーを介して行う必要があります。したがって、サーバーはトラフィック制御というもう 1 つの追加機能を受け取ります。私たちが作成したマルチユーザー チャットについて話している場合、プログラム コード全体は 2 つのモジュールで構成されます。

• クライアント - 認証、メッセージの送受信のためのグラフィカル インターフェイスが含まれています。

• サーバー側 - サーバー上でホストされ、ユーザーからメッセージを受信して​​処理し、受信者に送信する Web アプリケーション。

インターネット上で役立つ（またはあまり役に立たない）情報を見たいとき、私たちはブラウザを開いて検索バーにクエリを入力し、それに応じて検索エンジンから情報を受け取ります。このチェーンでは、ブラウザーがクライアントです。探しているものに関する情報を含むリクエストをサーバーに送信します。サーバーはリクエストを処理し、最も関連性の高い結果を見つけて、ブラウザ (クライアント) が理解できる形式にパッケージ化して送り返します。検索エンジンのような複雑なサービスでは、多数のサーバーが存在することがあります。たとえば、認可サーバー、情報を検索するサーバー、応答を生成するサーバーなどです。しかし、クライアントはこれについて何も知りません。クライアントにとって、サーバーは統合されたものです。クライアントは、エントリ ポイント、つまりリクエストの送信先となるサーバーのアドレスについてのみ知っています。前のパートで見た、すべての国の平均気温をリアルタイムで監視するためのアプリケーションを思い出してください。そのアーキテクチャは次のようになります。 私たちのアプリケーションはサーバー上にあります。たとえば、5 秒ごとに地元の水文気象センターのサーバーにリクエストを送信し、そこから特定の国の気温に関する情報を受信して​​、この情報を保存するとします。クライアントが「世界の現在の気温を確認したい」というリクエストで当社に連絡すると、保存されている最新の情報が国別に分類されて返されます。したがって、アプリケーションはサーバー (ユーザー要求を処理するとき) とクライアント (他のサーバーから情報を受信するとき) の両方になります。 単純なクライアント/サーバー アーキテクチャが使用されることはほとんどなく、非常に単純なアプリケーションにのみ使用されます。本当に大規模で複雑なプロジェクトの場合は、さまざまなタイプのアーキテクチャが使用されますが、これらについては今後さらに詳しくなるでしょう。次に、クライアント/サーバー モデルによく似たモデルを見てみましょう。

3層アーキテクチャ

これは、第 3 のプレーヤーであるデータ ウェアハウスを導入するアーキテクチャ パターンです。このパターンを使用する場合、通常、3 つのレベルはレイヤーと呼ばれます。

1. クライアント層はユーザー インターフェイスです。これは、HTML ページの送信先となる Web ブラウザー、または JavaFX を使用して作成された GUI アプリケーションである可能性があります。重要なことは、その助けを借りて、ユーザーがサーバーにリクエストを送信し、その応答を処理できることです。

2. ロジック層は、リクエスト/レスポンスが処理されるサーバーです。サーバー層とも呼ばれることがよくあります。数学的計算、データ操作、他のサービスやデータ ストレージへの呼び出しなど、すべての論理操作もここで行われます。

3. データ層はデータベース サーバーです。私たちのサーバーはデータベース サーバーにアクセスします。この層には、アプリケーションが動作中に使用する必要な情報がすべて保存されます。

したがって、ユーザーにデータへの直接アクセスを許可することなく、当社のサーバーがデータにアクセスするすべての義務を負います。

3層アーキテクチャの利点

このようなアーキテクチャを使用すると、次のような多くの利点が得られます。

1. SQL インジェクションに対する保護を構築する機能は、SQL コードが送信されるサーバーに対する攻撃であり、このコードが実行されると、攻撃者はデータベースに影響を与える可能性があります。

2. ユーザーアクセスを規制したいデータの境界。

3. クライアントに送信する前にデータを変更する機能。

4. スケーラビリティ - 同じデータベースを使用する複数のサーバーにアプリケーションを拡張できる機能。

5. ユーザーの接続品質に対する要件が少なくなります。サーバー上で応答を生成する場合、多くの場合、データベースからさまざまな情報を取得してフォーマットし、ユーザーが必要とする情報だけを残します。このようにして、クライアントへの応答として送信する情報の量を削減します。

アーキテクチャ パターンはどのくらいの頻度で使用する必要がありますか?

たとえば、 Factory Methodデザイン パターンに精通している場合は、それをいつ使用するか疑問に思ったことがあるでしょう。new 演算子を使用してオブジェクトを作成するか、ファクトリ メソッドを使用してオブジェクトを作成するか、何をすべきかを決めるのが難しい場合があります。しかし、時間が経つにつれて、理解が得られます。アーキテクチャパターンの場合は少し異なります。エンタープライズ フレームワークは、プログラマーがそれを使用して、一般的に受け入れられているパターンに基づいてプロジェクトを作成できるように設計されています。したがって、Spring Framework を学習する前に、クライアント サーバー アーキテクチャ、3 層アーキテクチャ、MVC アーキテクチャが何であるかを必ず理解する必要があります。心配しないでください。MVC アーキテクチャについては後で説明します。 パート 1. Spring と JavaEE を学ぶ前に知っておくべきこと パート 3. HTTP/HTTPS プロトコル パート 4. Maven の基本 パート 5. サーブレット。単純な Web アプリケーションの作成 パート 6. サーブレット コンテナー パート 7. MVC (Model-View-Controller) パターンの紹介 パート 8. 小さな Spring-Boot アプリケーションの作成