関して掘り下げていく。2層アーキテクチャと3層アーキテクチャ昔は各クライアントとデータベースサーバが直接接続する仕組みが存在した。それが2層アーキテクチャと呼ばれるものとしてありました。2層アーキテクチャは以下のような欠点を抱えていました。クライアントにすべてのロジックを詰め込むので、UIとビジネスロジックが密結合な状態になり、いずれかを変更すると互いに影響を受けてしまう複雑なことをやろうとすると処理できることがクライアントマシンのスペックに依存するため導入環境によって動きが代わってしまうDBと直接つながるので、人数が増えるとその分アクセス負荷も増大する。そこで間に中間のビジネスロジックを担当するサーバを間に入れる形が提案されました。それが3層アーキテクチャです。3層の場合はクライアント側が「プレゼンテーション層」と呼ばれるようになり、ビジネスロジックを担当するサーバは「ロジック(もしくはアプリケーション)層」、DBなどのデータを担当する部分を「データ層」という3層で呼ばれるケースが多い。層を分けることで何を期待したのか2層から3層に分けることで、以下のことを期待されていたプレゼンテーション(クライアント)側はUIだけ、ロジック層はビジネス部分の処理を、データ層はデータを管理するという形になり、機能毎に疎になる。クライアントとDBの間に1つ挟むことにより、裏側のデータ層のミドルウェアが変わったり、プレゼンテーション側のUIが変わっても間の層が適切なインターフェイスになっていればメンテナンスが容易。ビジネスロジック層は中央集権になるので、ロジックのミスなどに気づきやすい。レイヤードアーキテクチャに置き換えるレイヤードアーキテクチャと呼ばれるものも、利点としては同じ。物理的ではなくなった分、機能ごとに層をつくりやすくなり、責務ごとに層をつくることができる。「入門『状態』」という内容で登壇してきました。(3)はてなブログをはじめよう!shinkufencerさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。