2-tier 架構

遠古時期，狀態是完全由數據庫管理的。數據庫提供的連接是有狀態的，打開頁面的時候開連接，頁面上的改動直接提交到當前的數據庫連接。數據庫連接的狀態就是頁面狀態。

3-tier 架構

后來因為互聯網類型的應用的發展，數據庫無法承受更多的連接。所以頁面打開的時候不再開數據庫連接了，僅僅在渲染和提交操作的時候才開連接拿數據。在服務端 jsp 直接渲染頁面的 B/S 架構年代，狀態是這樣分布的

這樣的架構下，狀態管理仍然是非常簡單的。雖然有 database / jsp / html 三份狀態，但是數據源只有 database 一個。所有的改動都需要先提交到 database，然后重服務端 jsp 重新渲染，客戶端的 html 重新繪制。從數據遷移的角度來說，database => jsp 的網絡帶寬是非常高的，在內網情況下甚至 N+1 查詢都不是太大的事情。如果查詢實在太多了，手工寫幾個大 SQL 優化一下特定幾個 jsp 頁面的查詢就好了。

4-tier 架構

靜態 html 頁面的問題是 I/O 太慢了。所有的操作都需要提交到 database，然后再完整重新渲染。雖然 Ruby on Rails 有 Render Partial 之類的優化，可以用 jquery 做一個局部 div 的全刷新。但是仍然需要在網絡走一個完整的來回。現代的 Web Ui 需要操作更立即響應，需要在前端瀏覽器進行本地的計算和狀態管理。這就事實上變成了 4 tier 的架構。

React + Redux 自身是有狀態的一層。然后由單向數據流綁定到了 DOM 上，DOM 本身是沒有獨立的狀態的，完全由 React 驅動。這個架構改動的沖擊是非常大的。不是所有的改動都立即提交到數據庫了，而是有的時候提交到前端的 store 里就可以重新渲染了，有的時候需要提交命令給后端改數據庫。同時數據狀態遷移也更難做，外網的帶寬低延遲高，不能像 jsp 連數據庫那樣隨意查詢。Java 提供的 JSON 接口也需要定義更復雜的數據結構來支持前端頁面的渲染需求，以及提供數據校驗的結果。再加上前后端分工引起的團隊人員上的隔離，這個“帶寬低延遲高”的特點也體現在了跨角色的溝通上。

大部分 no code / low code 的解決方案是無法給開發者提供足夠的狀態控制能力的。因為讓開發者獨立管理前端狀態，比起頁面綁定數據庫要難太多了。所以市面上的 no code / low code 的平臺從狀態管理的角度來看是和遠古時期的 PowerBuilder / FoxPro 非常類似的理念。

5-tier 架構

更現代的 Ui 要求在界面上有更及時的動效反饋。例如滑動的時候可以有彈簧的效果，頁面切換的時候可以有滑出的效果。動畫的特點是要求至少 30 fps，也就是在 1000 / 30 ms 的時間內要計算出一幀的數據狀態，然后拿去做重渲染。用 javascript 勉強可以達到流暢，但是如果加上 React 的 virtual dom 計算就做不到流暢了。所以在 React / DOM 之間又架了一層“動畫狀態”層，比如 react-spring。這一層控制動效的狀態可以理解為 5th tier。

從 2-tier 到 5-tier 的驅動力至始至終都是相同的，就是 I/O 開銷。因為動畫計算不能發送到 React 端去計算，必須在 DOM 內本地計算，也是一種對 I/O 的優化。而不斷優化 I/O 的背后是用戶對 Ui 體驗越來越苛刻的要求。

未來的 N-tier 架構

未來會怎么發展？會不會因為 5G 網絡的發展使得 3-tier 架構復興？目前來看，光速短期只能無法被克服，面向延遲優化的傾向是不會變的，除非現代物理學有重大突破。同時因為大家對于跨屏融合體驗的要求越來越高，家里有小度的音箱，有投影儀，有手機。我們預期的是這些設備的體驗是一體的，和你在一個顯示器上的多個窗口不應該有本質區別。這樣帶來的結果必然是 5-tier 上還要再架上幾層。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的powerbuilder提示不是下拉窗口_为什么过去状态管理不是问题？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。