(譯者序)
「每個模式描述了一個在咱們周圍不斷重複發生的問題,以及該問題的解決方案的核心。這樣,你就能一次又一次地使用該方案而沒必要作重複勞動。」 ———— Christopher Alexander
招式套路能夠變幻無窮,紮實深厚的「內功」倒是始終如一;
(前言)
關於軟件架構的通用性的書籍,我推薦[POSA] —— 「面向模式的軟件體系結構」;
迭代開發的核心在於只要軟件對用戶有用,就應當交付,即便這個軟件當時並無完成;
(引言)
大多數重要的企業應用都是按照某種形式的層次分層設計的;
企業應用:
- 企業應用通常都涉及持久化數據;
- 企業應用通常都涉及大量數據;
- 企業應用通常都涉及不少人同時訪問數據;
- 企業應用通常都涉及大量操做數據的用戶界面屏幕;
- 企業應用不多獨立存在,一般須要與散佈在企業周圍的其餘企業應用集成;
企業應用是多種多樣的,不一樣的問題將致使不一樣的處理方法;
當構建企業應用系統時,關注硬件的可伸縮性每每比關注容量或效率更重要;
總的來講,購買新硬件仍是比修改舊軟件來得便宜;
模式的關鍵點是它們源於實踐;
使用模式的關鍵之一是不能盲目使用;
每一個模式相對獨立,但又不彼此孤立。有時候它們相互影響,如影隨形;
模式爲設計提供了一套詞彙,這也是爲何模式的名字這麼重要的緣由;
(P12)
在分解複雜的軟件系統時,軟件設計者用得最多的技術之一就是分層;
當用分層的觀點來考慮系統時,能夠將各個子系統想象成按照「多層蛋糕」的形式來組織,每一層都依託在其下層之上。在這種組織方式下,上層使用了下層定義的各類服務,而下層對上層一無所知。另外,每一層對本身的上層隱藏其下層的細節;
固然,並不是全部的分層架構都這麼隔絕,但絕大多數是不透明的,或至少是幾乎不透明的;
(P15)
根據不一樣的問題,選擇一種適合的分離方式,可是切記必定要進行某種形式的分離 —— 至少在子程序級別;
(P16)
只要有可能就用 Web 表現方式,只有在必需的狀況下才使用胖客戶方式;
(P19)
用「領域模型」而不是「事務腳本」正是面向對象的程序員所極力鼓吹的「理論體系轉換」的精髓;
(P20)
「領域模型」的價值在於你一旦掌握了它,就可運用許多現成的技術來較好地組織日趨複雜的領域邏輯;
(P21)
一旦習慣了「領域模型」,通常就能夠在未來很好地運用它,從而受益終生;
在許多方面,「表模塊」是「事務腳本」和「領域模型」的一箇中間地帶;
(P22)
開發小組的經驗越豐富,我越傾向於使用「領域模型」;
(P23)
「事務腳本」、「領域模型」和「表模塊」這三種模式並不互相排斥。事實上,使用「事務腳本」來處理一部分領域邏輯,同時使用「表模塊」或「領域模型」來處理剩下的部分,這也是很常見的;
處理領域邏輯的常見方法是將領域層再細分紅兩層。「服務層」獨立出來,置於底層的「領域模型」或「表模塊」之上。表現邏輯與領域層的交互徹底經過服務層,就好像應用程序的 API 同樣;
若是設立了服務層,在其中置入行爲的多少是一個相當重要的決定:
- 最小化狀況下,「服務層」只是一個外觀,全部實際的行爲都在下層的對象中,「服務層」所作的只是將上層調用傳遞到更低層。在這種狀況下,「服務層」提供一個更易於使用的 API ,由於它的方法一般根據用例來組織。此時,它也提供一個很方便的切入點,用來增長事務封裝和安全檢查等功能;
- 另外一個極端則是將大多數業務邏輯都以「事務腳本」的形式置於「服務層」中。下層的領域對象變得極爲簡單。若是下層是「領域模型」,則其中的對象與數據庫一一對應,於是此時你就可使用諸如「活動記錄」等較簡單的數據源層;
(P26)
清晰的 SQL 和領域邏輯分離是至關有益的;
(P27)
若是領域邏輯很是簡單而且類和表十分一致,使用「活動記錄」就足夠了;
若是領域邏輯比較複雜,「數據映射器」纔是須要的;
(P38)
儘可能使用已預先編譯好的靜態 SQL ,而不是每次都編譯動態 SQL ;
(P62)
本地接口最好是細粒度接口。細粒度接口很是好,由於它符合通常的面向對象原則,即儘可能細分對象,使咱們能夠以不一樣方式組合和覆蓋這些對象以便在未來對設計進行擴展;
(P63)
只有在沒法使用系統本身的遠程調用機制時,才使用基於 XML 的 Web Service ;
(P77)
「事務腳本」勝在簡單,對於只有少許邏輯的應用程序來講,使用這一模式很是天然,不管在性能上仍是理解上都不會帶來太大的開銷;
(P81)
「領域模型」與系統中其它層之間的耦合程度應達到最小;
(P83)
要熟悉「領域模型」須要實踐和訓練,可是一旦掌握了它,我發現除了解決最簡單的問題外,不多會有人再使用「事務腳本」;
(P86)
「策略類」的巨大價值在於提供了一些良好封裝的插入點,來進行應用程序擴展;
(P87)
在面向對象技術中,經過從一個對象到另外一個對象的連續傳遞能夠把行爲傳給最有資格處理的對象,它同時也消除了許多條件判斷行爲;
類似的條件判斷語句能夠提取到對象結構自己之中;
(P88)
面向對象的關鍵思想之一是將數據與對該數據操做的行爲綁定在一塊兒;
(P94)
「服務層」定義了應用的邊界和從接口客戶層角度所能看到的可用操做集。它封裝了應用的業務邏輯、事務控制及其操做實現中的響應協調;
「服務層」類的接口是粗粒度的,就接口粒度而言,「服務層」類很適合於遠程調用;
(P96)
「服務層」的設計思想來自於應用邊界模式;
「服務層」的優勢在於它定義了一個公共的應用操做集合,這一集合可被各類客戶使用,並且服務層在每一個操做中都會協調應用的響應;
(P99)
「服務層」這一設計模式爲封裝應用的業務邏輯、實現和支持不一樣的客戶以一致的方式調用這些邏輯奠基了基礎;
(P101)
「表數據入口」接口很簡單,通常包括幾個從數據庫中獲取數據的查找方法以及更新、插入和刪除方法;
(P102)
「表數據入口」和「領域模型」不多一塊兒使用,由於「數據映射器」更好地分離了「領域模型」和數據庫;
「表數據入口」能夠同「表模塊」一塊兒很好地使用;它產生一個記錄集數據結構由「表模塊」處理;
(P103)
在 .Net 環境下,當操做大量信息但又不想一次把所有信息都調入內存時,數據閱讀器是合適的選擇;
(P107)
一般很難說清「行數據入口」和「活動記錄」之間的區別,這個問題的關鍵要看是否存在任何領域邏輯。若是存在,則是「活動記錄」。「行數據入口」僅包含數據庫邏輯而沒有領域邏輯;
(P275)
進程間調用的開銷比進程內調用的開銷更大 —— 即便兩個進程都在同一臺機器上;
(P340)
.Net 對值對象有良好的支持機制,在 C# 中經過聲明一個對象爲結構而不是類就將它標記爲值對象;
(P352)
若是依賴於徹底不受本身控制的外部資源,一般會使軟件項目受挫;程序員