私はちょうど講義を見ました：
彼は、接続プーリングの問題が原因で 3 層パラダイムが始まったと言い続けています。
アーキテクチャ上の考慮事項のためではありません。
気が遠くなるような理論のようです。
誰かがこの主張を証明または反証できますか?
質問する
127 次
1 に答える
0
これは、適切に答えるのが難しい質問です。プレゼンテーションの関連部分は、データベースが数十の接続用に設計されていないため、アプリケーションとデータベース内のストアド プロシージャの間に導入されたビジネス レイヤーが必要であると述べています。
失礼ですが同意できません。ビジネス ロジック、プレゼンテーション、および状態の保存を分離するというアイデアは、1970 年または 1980 年にさかのぼります。ウィキペディアによると、Xerox PARC で開発されました。
もちろん、当時のサーバーは現在よりもはるかに高価でした。しかし、それでも彼らは保守性やソフトウェア開発の他の側面、つまりテスト、デバッグ、および完全な製品の開発の一部を別のチームに割り当てることについて考えることをやめませんでした。統合アプリケーション内で厳密に定義されたインターフェイスを持つことは、接続プーリングのためではなく (混合物全体の構成要素の制限を回避するだけです)、より重要なこととして、アプリケーションを保守可能に保ち、開発を簡素化するために非常に理にかなっています。プロセス。
話は好きだけど。実践から、やみくもにデザイン パターンに同意すると、望ましくない状況に陥る可能性があることを私は知っています。あなたはいつでもすべてをやり過ぎることができます。
要するに、多層モデル (個々のサーバー上であれ、開発パラダイムとしてであれ) は、インターネットの台頭よりも古いものです。少なくとも1980年以降は当たり前のようになっています。
于 2013-04-13T18:20:23.983 に答える