CodeGym /Java Blog /ランダム /パート 2. ソフトウェア アーキテクチャについて少し話しましょう
John Squirrels
レベル 41
San Francisco

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

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

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

この名前は、このパターンのすべてがシンプルで明確であるという印象を与えます。ただし、Spring の学習を開始するときに私たちが話していることを理解できるように、いくつかの点を明確にしましょう。あなたがチャット アプリを作成し、あなたと友人がそれを使い始めたとします。既知の IP アドレスを使用してインターネット経由でメッセージを直接相互に送信する、非常に単純なアプローチを採用することもできます。 パート 2. ソフトウェア アーキテクチャについて少し話しましょう - 2最初は、別の友達がチャットへの参加を要求するまで、すべてがうまく機能しているように見えます。そのため、共通の友人をチャットに追加することにした場合、アーキテクチャ上の問題に直面します。チャット参加者ごとに、ユーザーの数と新しいユーザーの IP アドレスに関する現在の情報を提供する必要があります。また、メッセージが送信されると、すべての参加者に配信される必要があります。これらは、発生するであろう最も明白な問題です。さらに多くの問題がコード自体に隠されています。それらを回避するには、サーバーを使用する必要があります、アドレスを含むユーザーに関するすべての情報が保存されます。メッセージはサーバーに送信するだけで済みます。次に、各受信者にメッセージを送信します。チャット アプリにサーバー部分を追加すると決めたら、クライアント/サーバー アーキテクチャの構築を開始することになります。

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

それが一体何なのか見てみましょう。クライアント/サーバー アーキテクチャは、 Web アプリケーションの作成に使用される設計パターンです。このアーキテクチャは、次の 3 つのコンポーネントで構成されます。 パート 2. ソフトウェア アーキテクチャについて少し話しましょう - 3
  1. クライアント — その名前から、このコンポーネントが何らかのサービス (Web アプリケーション) を使用し、サーバーに接続して情報を要求していることがわかります。

  2. サーバー — Web アプリケーションまたはそのサーバー部分が配置される場所です。必要なユーザー情報を保存したり、要求したりできます。さらに、クライアントがリクエストを送信すると、リクエストされた情報を返すのはサーバーです。

  3. ネットワーク — この部分は単純です。これにより、クライアントとサーバー間の情報交換が容易になります。

サーバーは、さまざまなユーザーからの膨大な数のリクエストを処理できます。これは、クライアントが多数存在する可能性があることを意味します。相互に情報を交換する必要がある場合は、サーバーを介して行う必要があります。したがって、サーバーにはトラフィック制御という別の機能があります。マルチユーザー チャット プログラムに関連して、アプリケーション全体は次の 2 つのモジュールで構成されます。
  • クライアント モジュール — サインインおよびメッセージの送受信のためのグラフィカル インターフェイスが含まれています

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

パート 2. ソフトウェア アーキテクチャについて少し話しましょう - 4インターネット上で役立つ (またはあまり役に立たない) 情報を見たいときは、ブラウザを開いて検索バーにクエリを入力し、それに応じて検索エンジンから情報を取得します。このチェーンでは、ブラウザーがクライアントになります。探しているものに関する情報を含むリクエストをサーバーに送信します。サーバーはリクエストを処理し、最も関連性の高い結果を見つけて、ブラウザ (クライアント) が理解できる形式にパッケージ化して送り返します。検索エンジンのような複雑なサービスには、多数のサーバーが存在する場合があります。たとえば、認可サーバー、情報を検索するサーバー、応答を生成するサーバーなどです。しかし、クライアントはこれらを認識せず、気にも留めません。クライアントにとって、サーバーは統合されたエンティティです。クライアントはエントリ ポイントについてのみ知っています。つまり、リクエストの送信先となるサーバーのアドレス。で調べたアプリケーションを思い出してください。このシリーズの前の部分。これは、各国の平均気温をリアルタイムで監視するためのものでした。そのアーキテクチャは次のようになります。 パート 2. ソフトウェア アーキテクチャについて少し話しましょう - 5アプリケーションはサーバー上にあります。5 秒ごとに、地元の気象観測所が運用するサーバーにリクエストを送信し、サーバーから特定の国の気温情報を受信して​​、この情報を保存するとします。クライアントが「世界の現在の気温を表示」するように要求すると、最後に保存された情報が国ごとにソートされて返されます。したがって、アプリケーションはサーバー (ユーザー要求を処理するとき) とクライアント (他のサーバーから情報を受信するとき) の両方として機能します。
ここで重要な点があります。サーバーの概念は特定のコンピューターに関するものではなく、ネットワーク エンティティ間の関係に関するものです
単純なクライアント/サーバー アーキテクチャが使用されることはほとんどなく、非常に単純なアプリケーションにのみ使用されます。本当に大規模で複雑なプロジェクトの場合、私たちはさまざまなアーキテクチャを使用します。これらのアーキテクチャについては、今後ご紹介します。次に、クライアント/サーバー アーキテクチャによく似たモデルを見てみましょう。

3層アーキテクチャ

これは、3 番目のモジュールであるデータ ストレージを導入するアーキテクチャ パターンです。このパターンでは、3 つのレベルは通常レイヤーまたは層と呼ばれます。 パート 2. ソフトウェア アーキテクチャについて少し話しましょう - 6
  1. クライアント層はユーザー インターフェイスであり、プレゼンテーション層とも呼ばれます。これは、HTML ページを受信する Web ブラウザ、または JavaFX を使用して作成されたグラフィカル ユーザー インターフェイスです。重要なことは、この層により、ユーザーがサーバーにリクエストを送信し、その応答を処理できるようになります。

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

  3. データ層はデータベース サーバーです。サーバーはデータベース サーバーと対話します。この層には、アプリケーションの動作に必要なすべての情報が格納されます。

したがって、当社のサーバーはデータへのアクセスに対するすべての責任を負い、ユーザーがデータに直接アクセスすることを許可しません。

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

このようなアーキテクチャには、次のような多くの利点があります。
  1. SQL インジェクションから保護する機能 (これはサーバーに対する攻撃です。実行すると、攻撃者がデータベースに影響を与えることを可能にする SQL コードの送信が含まれます)。

  2. ユーザーアクセスを制御したいデータの分離。

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

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

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

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

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