昨天,突然和阿敏談起領域模型,發現自己的理解還是有些歧異於是看了罈子裡robbin關於領域模型的一些**,又吧...老馬的企業應用架構模式拿出來翻了翻好象又增加了些理解,領域模型大體分為三種(也可分為四種)分別為失血,貧血,充血/(脹血)(robbin語)下面我總結了幾條關於領域模型幾個形態的一些不成熟的總結:
一:失血模型,首先分為po,dao,service三大塊,在這裡po就是領域層,但它只是個承載值的物件,除了屬性並沒有其他的方法所以在這裡領域並沒有起到它控制業務的作用,由於只有屬性所以我們叫它失血,而dao層只做和資料庫的互動使得業務操作和資料庫操作分離,其中service層則作為乙個操作的載體,其中有關於物件的所有操作,包括物件所要涉及到的集合類操作,並在這裡做關於事務等的管理.
二:貧血模型:同樣分為剛才失血模型的幾層,但它和失血模型的區別在於領域層中,除了基本屬性外還包含關係此物件的一些方法(這些方法不涉及資料庫操作)例如一些臨時物件的組成,或對物件中的值的分析等操作,service則是做集合類的操作,以及對在domain層中所涉及到的物件的操作並對這些操作進行封裝,以保證事務和結構的完整性.此模型可充分體現oo特點!(個人體會)
三:充血模型,層次也是domain,dao,service三層,但在領域層中管理所有的**包括集合和物件的操作,service只當成乙個介面並沒有太多實際**只是對domain中**的封裝,在robbin的帖子中,貌似談到需要在domain中進行事務,但我認為為了保持事務完整的特點事務可能在service控制相對更貼切些!
另外還有一種貌似是同仁們總結出的一種所謂的脹血模型,就是說把service也喀嚓掉,只留dao和domain而domain做所有的處理,雖然這不失為一種快速開發的手段,但個人感覺已經完全脫離oo的思想了,好象幾種特性都沒體現出來...如果專案的模組以及規模相對較大我想此模型應該不能勝任.
以上是我自己的一些看法並不成熟也許本身說的就是錯的,還需要繼續看看老馬的那本書,能夠有個更深的體會.其實我認為各個專案自然有它自己的特點不應該循規蹈矩必須按照哪種模型,沒有最好只有更好其實就是這樣只有選擇對的,才可能在專案中減少成本,時間開發量並對專案以後的維護起乙個積極的引導作用!
又談「裝系統」
開始學裝系統是去年的11月份，我們在師兄的指導下，對自己的本裝了有重灌，來來回回整整了四五遍。以為已經很差不多了，一下子對計算機裝系統不在有神秘感。最近vb作品展完後，自己的本搞的亂七八糟，我又重灌了一次系統，沒想到，又意外收穫了一把。在這裡我就整理一下我知道的裝系統的方法吧。四個方法 一 光碟安裝...
又談「裝系統」
開始學裝系統是去年的11月份，我們在師兄的指導下，對自己的本裝了有重灌，來來回回整整了四五遍。以為已經很差不多了，一下子對計算機裝系統不在有神秘感。最近vb作品展完後，自己的本搞的亂七八糟，我又重灌了一次系統，沒想到，又意外收穫了一把。在這裡我就整理一下我知道的裝系統的方法吧。四個方法 一 光碟安裝...
又談F分布
今天看到一篇不錯的博文，有感，記錄下來，相對來說講到了本質，也很容易理解。首先，老生常談，還是那三大分布 t，卡方，f，正態不是三大 t是厚尾的，對小樣本量做檢驗，對於樣本難獲得的領域很有用，比如醫藥，生物，前面寫過乙個關於t檢驗的記錄。卡方檢驗用來做獨立性檢驗和符合某個標準分布 正態檢驗 n個相互...