P of EAA : Layering

Layering 是軟體設計師最常用的技巧,可以將複雜的軟體系統打散。上層依賴下層,下層不知道上層。最好的例子就是我們的網路 OSI 七層架構了(現在通常簡化為四層了)。

Layering 的好處很多,你可以只知道一層不用知道全部、可以替換任一層、容易標準化、上層可以有各種選擇等(例子想OSI吧)。缺點是可能會帶來 cascading changes (因為每層layer包了某些東西,但是又沒有全部都包的好好的),你如果要在UI多一個欄位,嗯,那個欄位也要在database,嗯,每一層都要加上那個欄位的處理… XD。另一個缺點就是多餘的Layer會降低整體效能,但往好處想,某一層做好最佳化,上面的都會受益。

困難的地方在於各層要有什麼以及每一層應該要有的責任。

本書使用 Three Principal Layers 來討論 : Presentation, Domain (Logic), and Data Source 。你應該可以想到大概是怎樣了,我就不寫了 :p

幾個重點像是 domain 跟 data source 不應依賴 presentation,保持替換 Presentation 的空間。而 domain 和 data source 之間的關係則要看你用的 architectural patterns 了。

一個困難點決定哪些 logic 在 domain,因為我們常把 domain logic 放到 presentation 去。作者提了一個簡單的測試方法,請你想像另一種很不同的 layer 情況,如把 web interface 換成 command-line ,看看是不是有功能重複了,如果有就應該搬到 domain logic 去。

本章最後談選擇 你要在哪裡跑你的 layer。通通跑在 server 是最簡單的作法(如用web browser當client),因為容易升級跟補釘囉。看起來都跑 server 就好啦,但是為了 responsiveness 回應速度 或 disconnected 離線使用 這兩個原因,你也許得跑東西在 client 上。

本書假設 data source 都在server跑,因為若是要跑離線的情況,就得處裡 client 跟 server 同步的情況,嗯,作者說這不在本書範圍 :p 後記: 你可以找找 Data Patterns 的資源

presentation 如何? 這要看你的 user interface 類型了,跑視窗顯然你得放在 client,跑web就是放server囉(有個例外是X servers in Unix)。

domain logic 放 server 容易維護,而會放 client 的理由就是為了回應速度跟離線。兩邊都放一點顯然會變複雜,盡量不要醬子。

發佈留言

發表迴響

%d 位部落客按了讚: