リッチクライアントなシステムについて

Question

一昔前の二層モデルについて質問です。
「達人に学ぶDB設計徹底指南書」という本に以下のような記述があります。

「（プレゼンテーション層、アプリケーション層、データアクセス層のWeb三層モデルに関して）実は歴史的に振り返ると、かつてはこのアプリケーション層が存在しないモデルが主流でした。クライアントとサーバーだけからなる「二層モデル」が主流だったのです。このモデルでは、プレゼンテーション層とアプリケーション層がクライアント側に位置し、データ層だけがサーバー側にありました。年配のエンジニアの方は覚えていると思いますが、当時はクライアントにVisual Studioなどの製品でGUIアプリケーションを作っていたものです。かなりクライアントに多くの仕事をさせるリッチクライアントなシステムでした。
このモデルには以下のような欠点がありました。

1. 業務を実現するためのビジネスロジックに変更が生じた場合、いちいちすべてのクライアントのプログラムを更新しなければならないのが煩雑。
2. 性能の貧弱なクライアントでは複雑な処理が実現できない。
3. サーバーとクライアントの通信量が多く、ネットワーク帯域の狭かった昔は回線がボトルネックになった。

こうした理由から、ビジネスロジック層とユーザーインターフェースを分離し、前者をサーバ側に持ってくることが3層モデルの着想でした。最終的には、ユーターインターフェースを担うプレゼンテーション層もサーバ側に移されたため、最近のクライアントにはWebブラウザさえ入っていれば他に何のアプリけーしょんもインストールする必要は無くなりました。」

基本的にはWebアプリの話だと思うのですが、1の欠点はどういうことなのでしょうか？
基本的にはサーバにアプリケーションがあって、そのアプリケーションをネットワークを通じて、クライアントに送信しているのがこの二層モデルですよね？
そうすると、ビジネスロジックに変更があっても、その変更した後にアプリケーションをクライアントに送信すれば、何の問題もなく、実行できると思うのですが、何が煩雑なのでしょうか？
お分かりの方、回答お願いします。

Answer 1

二層モデル、俗に言うクラサバシステムです。Webアプリの話では無いです。

例えば、
各マシンに「サーバーのデータベースを直接操作するアプリ」をインストールして使う。

と言えば、イメージしやすいのかな。

この場合、アプリに変更があれば、全マシン再インストールですよね。

Webシステムが無い昔は当たり前でしたが。

Comments

[退会済みユーザー]

よくわかりました。
ありがとうございました。