事務指令碼和領域模型之間的區別還是很明顯的,顯然,我們常見的系統中沒有太多是採用領域建模來實現的;而大部分是採用事務指令碼來實現。
我承認事務指令碼在解決簡單問題方面確實是簡單,特別是只是簡單的crud問題。
事務指令碼的乙個最重要的特徵是:
1. 簡單的過程模型。也就是乙個service方法就對應著使用者的乙個命令,該命令通過行資料入口或者表資料入口來完成取資料操作,以及其它的資料處理操作。
2. 行資料入口 或者 表資料入口。資料庫中的記錄對應乙個物件,還是查詢出來是對應資料庫的記錄集。行資料入口:為查詢語句返回的每一行產生乙個它的例項。這也應該是先行的很多orm工具使用的方法。表資料入口:為查詢語句返回乙個記錄集。對資料庫中的每個表,僅僅使用乙個物件來管理。
3. 事務的邊界:開始於指令碼的開啟,終止於指令碼的關閉。也就是事務邊界就是在service方法上。
在專案中,操作方式就是從service -> dao -> db。我們資料庫層採用的是orm對映,資料庫表和實體是一一對映關係,和行資料庫入口差別不大。對於系統當中只有增刪改查的情況,用這種方式相當直觀,並且良好,不會有什麼問題。
但是,在系統的業務邏輯比較複雜的地方。雖然,我現在搞不清楚,到底有哪些地方業務邏輯比較複雜。可能最為複雜的地方是在度量吧,度量那部分有很多計算。
一切在後面的發展過程中去看吧。現在不能簡單的下結論,只要**良好,問題都不大。
事務指令碼和領域模型
事務指令碼 事務指令碼的核心是過程,通過過程的呼叫來組織業務邏輯,每個過程處理來自表現層的單個請求。大部分業務應用都可以被看成一系列事務,從某種程度上來說,通過事務指令碼處理業務,就像執行一條條sql語句來實現資料庫資訊的處理。事務指令碼把業務邏輯組織成單個過程,在過程中直接呼叫資料庫,業務邏輯在服...
業務邏輯層之事務指令碼與領域模型
在前面的部落格中,已了解了前端控制器,頁面控制器,應用控制器這三種表現層模式,如果說它們精心安排了外部世界與系統內部的通訊,那麼業務邏輯層的工作則是處理應用程式的業務部分。業務邏輯層應當遠離那些外部的 噪音 業務邏輯是整個應用程式的根本目的所在,系統的其它部分都是為這部分服務的。這裡介紹兩種經常使用...
富領域模型和貧血領域模型
貧血領域模型乙個明顯的特徵是 它僅僅是看上去和領域模型一樣,都是物件,都以領域空間中定 義的名詞命名,這些物件通過實際領域模型中豐富的關係和結構相互關聯。但是觀察模型所持有的 業務邏輯時會發現,貧血模型中除了大量 getter 和 setter,幾乎沒有其他業務邏輯。當然,在使用貧血領域模型時,那些...