最近看了robbin關於再次小結領域模型的種種觀點 的大作 摘抄如下:
一、失血模型
失血模型請看
中列舉的第一種模型，簡單來說，就是domain object只有屬性的getter/setter方法，沒有任何業務邏輯。
二、貧血模型
貧血模型請看
中列舉的第二種模型，簡單來說，就是domain ojbect包含了不依賴於持久化的領域邏輯，而那些依賴持久化的領域邏輯被分離到service層。
service(業務邏輯，事務封裝) --> dao ---> domain object
這種模型的優點：
1、各層單向依賴，結構清楚，易於實現和維護
2、設計簡單易行，底層模型非常穩定
這種模型的缺點：
1、domain object的部分比較緊密依賴的持久化domain logic被分離到service層，顯得不夠oo
2、service層過於厚重
三、充血模型
充血模型和第二種模型差不多，所不同的就是如何劃分業務邏輯，即認為，絕大多業務邏輯都應該被放在domain object裡面(包括持久化邏輯)，而service層應該是很薄的一層，僅僅封裝事務和少量邏輯，不和dao層打交道。
service(事務封裝) ---> domain object <---> dao
這種模型的優點：
1、更加符合oo的原則
2、service層很薄，只充當facade的角色，不和dao打交道。
這種模型的缺點：
1、dao和domain object形成了雙向依賴，複雜的雙向依賴會導致很多潛在的問題。
2、如何劃分service層邏輯和domain層邏輯是非常含混的，在實際專案中，由於設計和開發人員的水平差異，可能導致整個結構的混亂無序。
3、考慮到service層的事務封裝特性，service層必須對所有的domain object的邏輯提供相應的事務封裝方法，其結果就是service完全重定義一遍所有的domain logic，非常煩瑣，而且service的事務化封裝其意義就等於把oo的domain logic轉換為過程的service transactionscript。該充血模型辛辛苦苦在domain層實現的oo在service層又變成了過程式，對於web層程式設計師的角度來看，和貧血模型沒有什麼區別了。
四、脹血模型
基於充血模型的第三個缺點，有同學提出，乾脆取消service層，只剩下domain object和dao兩層，在domain object的domain logic上面封裝事務。
domain object(事務封裝，業務邏輯) <---> dao
似乎ruby on rails就是這種模型，他甚至把domain object和dao都合併了。
該模型優點：
1、簡化了分層
2、也算符合oo
該模型缺點：
1、很多不是domain logic的service邏輯也被強行放入domain object ，引起了domain ojbect模型的不穩定
2、domain object暴露給web層過多的資訊，可能引起意想不到的***。
在這四種模型當中，失血模型和脹血模型應該是不被提倡的。而貧血模型和充血模型從技術上來說，都已經是可行的了。但是我個人仍然主張使用貧血模型。其理由：
1、參考充血模型第三個缺點，由於暴露給web層程式拿到的還是service transaction script，對於web層程式設計師來說，底層oo意義喪失了。
2、參考充血模型第三個缺點，為了事務封裝，service層要給每個domain logic提供乙個過程化封裝，這對於程式設計來說，做了多餘的工作，非常煩瑣。
3、domain object和dao的雙向依賴在做大專案中，考慮到團隊成員的水平差異，很容易引入不可預知的潛在bug。
4、如何劃分domain logic和service logic的標準是不確定的，往往要根據個人經驗，有些人就是覺得某個業務他更加貼近domain，也有人認為這個業務是貼近service的。由於劃分標準的不確定性，帶來的後果就是實際專案中會產生很多這樣的爭議和糾紛，不同的人會有不同的劃分方法，最後就會造成整個專案的邏輯分層混亂。這不像貧血模型中我提出的按照是否依賴持久化進行劃分，這種標準是非常確定的，不會引起爭議，因此團隊開發中，不會產生此類問題。
5、貧血模型的domain object確實不夠rich，但是我們是做專案，不是做研究，好用就行了，管它是不是那麼純的oo呢？其實我不同意firebody認為的貧血模型在設計模型和實現**中有很大跨越的說法。乙個設計模型到實現的時候，你直接得到兩個類：乙個實體類，乙個控制類就行了，沒有什麼跨越。
下面就專案中的應用具體對比下:
我們現在做的乙個專案 有存在衝突： 一方是要求採用脹血模型 另一方是要求採用貧血模型 。 關於這兩兩種的模型的優缺點。。。後續
關於vertical align的種種
有些時候vertical align的渲染結果並不同我們想象的一樣。雖然現在已經有很多 css 屬性可以完美替代vertical align的渲染效果，但有些時候碰到還是很頭疼，所以最好還是搞清楚它。作用物件 inline inline block子元素。這個屬性失效的情況 作用物件是塊級元素 因為...
關於vim使用的種種
裝了64位20.04的ubuntu以後下一步是安裝docker。然後我在網上搜了個教程，照著搞了半天都搞不出來，然後我就絕望的找到了我的小夥伴，發現直接docker然後提示我讓我裝啥我就裝啥就簡單的解決了。非常的簡單，我白白浪費了兩個小時。sudo docker pull litangpku nac...
關於 友元函式 的 種種
1 友元函式 通過物件的引用 可以直接 訪問私有變數，不能直接訪問私有變數 而一般的函式則不可以。2 友元是一種定義在類外部的普通函式，但它需要在類體內進行說明，為了與該類的成員函式加以區別，在說明時前面加以關鍵字friend。友元不是成員函式，但是它可以訪問類中的私有成員。友元的作用在於提高程式的...