說來慚愧, 某日專案組成員交上來領域模型類圖,將物件的屬性和方法分類,基本上統統使用了domainobject-domainobjectmanager的方式,前者之後屬性以及對應的getter-setter方法,後者包含具體的業務操作.在我詢問為什麼要這麼做的時候,對方反問為什麼不能呢,我說這樣不符合oo,oo的物件是具有屬性已經在此屬性上具有操作能力的一種東西,他說分開來一部分用作po對應資料庫表,動作部分用來做基本業務處理難道不好嗎? 我一時語塞...只能飲用robin的一段:
[quote]首先要區別持久物件和pojo。
持久物件實際上必須對應資料庫中的entity，所以和pojo有所區別。比如說pojo是由new建立，由gc**。但是持久物件是 insert資料庫建立，由資料庫delete刪除的。基本上持久物件生命週期和資料庫密切相關。另外持久物件往往只能存在乙個資料庫 connection之中，connnection關閉以後，持久物件就不存在了，而pojo只要不被gc**，總是存在的。
由於存在諸多差別，因此持久物件po(persistent object)在**上肯定和pojo不同，起碼po相對於pojo會增加一些用來管理資料庫entity狀態的屬性和方法。而orm追求的目標就是要 po在使用上盡量和pojo一致，對於程式設計師來說，他們可以把po當做pojo來用，而感覺不到po的存在。 [/quote]
難道這就是傳說中的貧血domian model,而所謂的service其實就是這些個manager的集合?
[img]
也談Linux下的資料備份
資料的價值自不待言，損壞後重新生成需要花費寶貴的時間和令人絕望的努力，有時甚至不可能重新產生，例如一些一次性不可逆測試實驗的。由於資料是一種投資，你必須保護它，並採取措施避免丟失。否則並且要花費高昂的金錢來挽救，有時也得配上淚水 看看 9.11事件 的悲慘一幕，這樣的話語可不是危言聳聽 眾多的伺服器...
返樸歸真,也談 物件導向程式設計的幾個原則
1.開閉原則 the open closed principle ocp 2.替換原則 the liskov substitution principle lsp 子類應當可以替換父類並出現在父類能夠出現的任何地方。這個原則是liskov於1987年提出的設計原則。它同樣可以從bertrand me...
返樸歸真,也談 物件導向程式設計的幾個原則
1.開閉原則 the open closed principle ocp 2.替換原則 the liskov substitution principle lsp 子類應當可以替換父類並出現在父類能夠出現的任何地方。這個原則是liskov於1987年提出的設計原則。它同樣可以從bertrand me...