這幾天有比較熱鬧起來，最近新書進入收尾階段空閒時間也有了，所以也來湊湊熱鬧，其實主要是看過以下面兩個post，有些感想，所以寫下來也歡迎各位大中小蝦批評指正。
一篇是：
比較hibernate和ado.net 2.0，問？hibernate還有什麼特性更值得期待？
一篇是：
域模型向左走(充血)，向右走(貧血)
很多大蝦都提出了自己的主張看法，針對這這兩篇主題已經有很充分的討論鳥，這裡我只想針對其中所涉及的兩個方面的問題說說自己的看法
乙個是物件持久化，乙個是orm。
首先，什麼是物件持久化？為什麼要持久化物件？
針對這個問題主要是在第一篇裡的徐大俠所提的ado.net2.0對物件持久化的支援的問題。所謂的物件持久化，首先，這個必須是在完全ood，ooa，oop的程式裡才可能出現的概念，當然，沒有物件何來的持久化？我們在設計程式的時候，通過用例對問題的領域進行描述，就我個人的觀點來說，其實用例在領域模型建立的過程中或者是我們建立乙個問題域的過程當中作用是最大的，基本上再細化之後所挖掘出來的東西就很難oo的去理解了（最終到了資料庫這個級別的時候是沒法oo的，比如sqlhelper，基本上的結構就是一大堆的靜態方法，其實是不用搞什麼用力分析了的）。而程式在執行的過程當中，所有的類和物件都是儲存在記憶體當中的，而類的狀態（也就是屬性）在記憶體當中是無法永久存在的，因為記憶體的可揮發性，所以當程式重新啟動後是無法保持所有物件的狀態，比如我們在程式開始預設建立了10個使用者的物件，但是在執行的過程中修改了乙個使用者的暱稱屬性，這個時候如果我們重新啟動程式，那麼這個使用者的暱稱屬性被改變後的狀態是沒有辦法儲存的。這個時候我們就需要將這個物件的狀態（所有屬性的值-----也不一定是所有，因為有的屬性是依據其他屬性的，最終還是看設計而言，反正就是在設計上需要儲存下來的屬性）儲存下來，並且可以在需要的時候隨時載入到記憶體中。這個就是物件的持久化。
那麼我們怎麼來持久化物件呢？那方法就多了，我們可以通過序列化將類平面化後儲存在檔案系統，或者通過資料庫元件將物件的狀態儲存到資料庫中。我們會在資料庫中設計表結構來儲存物件的屬性，並且能夠在資料庫中快速索引到某乙個物件儲存的狀態，並且快速恢復到記憶體中。
最後的結果就是說oo不好，預先設計浪費時間，用起來彆扭，其實不是oo不對，而是人不對，因為發現這些問題的時候我們完全都把過程搞反了，而這些錯誤是我們常犯的，而且很多時候還會人窮怪屋畸的責備oo的問題，其實oo並沒有問題，我們的問題確是更大一些。
設計為什麼要自頂向下？這裡我們要特定在有一定業務邏輯的業務系統，寫驅動的牛人就不必看這段了。
因為所謂的業務系統一定是以符合業務的規範，用業務作為設計的約束才能夠真正的做好乙個系統，至於實現的細節，哇塞，大家都是出來靠寫程式吃飯的，讀寫資料庫，寫日誌........說白了程式在最終實現的時候都是這些東西，至於事務啊，執行緒安全啊，跨程序同步啊，這些囉唆的問題就是在設計架構的時候考慮的問題了，而這些也是架構師要考慮的問題。而比如enterpriselab就是做這個的，當然我們自己來實現乙個類似的東西也沒有關係，總之這是個大框架，可復用的，我們只需要設計好業務相關的類放進去就可以了（理想情況，大多是時候我們還是要自己做很多囉唆的事情）。
自頂向下能不能xp？當然，我們完全可以快速的搭建好框架，然後寫出測試用例，在類中都用偽邏輯實現，這個時候資料庫都沒開始設計呢我們就可以開始測試了，夠xp了吧，我們可以在開始的時候就對業務設計做充分的設計，並且在得到穩定的同時最後去完成資料庫的設計以及實現持久化。（資料庫最好要穩固，不要動不動就來個大變樣，萬一休假乙個星期去旅遊一趟回來見他就不認識了就太糟糕了）所以其實自頂向下更需要單元測試，更加的xp。
而且現在對於持久化的功能有orm這個利器，我們完全可以用aop將持久化的能力注入我們我麼設計的類中去，讓物件具備被持久化的能力。
這下我們談到orm了，對於什麼是orm我們不用多說了，到處都是解釋。
按我的理解，orm就是乙個將資料庫的結構轉化成物件的狀態的轉化器。
那我們用orm來幹什麼呢？我認為orm的作用就是為物件實現持久化的能力，如果這樣子理解的話即使是我們僅僅把orm當作乙個好用的cuid工具來使用也不會有太大的問題，當然如果對orm使用比較熟練的話可以通過配置完成持久化的功能當然更好。所以其實不管貧血還是充血，fatservice還是thinservice，只要我們在設計的時候延續正確的方法，那麼我們就不會感覺到彆扭。
理想和現實是有差距的，首先，此方法遺留系統不適用，太大的遺留系統這樣子重構的話，那不是人能幹的活。其次沒有好的架構設計師的話沒法用，對業務的理解都有問題，分析用例類沒找對........結果還是痛苦。再次編碼的程式設計師素質要足夠，不然理解不到位，使用起來還是這麼的彆扭（起碼在編碼人員看起來是）。
鄧爺爺說：不管白貓黑貓，能逮住耗兒的就是好貓。這是實用主義者的寶典，但是我們不能因為這樣子就裹足不前，因為現實的約束就不去追求實現的優美，逮住耗兒也要看是輕輕鬆鬆信手拈來還是一路筋斗鼻青臉腫的逮住耗兒，能夠完善我們的設計為什麼不去完善呢？
大家知道，我的廢話很多，所以來湊熱鬧
很久很久以前，具體不記得了，大約是96年左右吧，北京展覽館搞電腦節的時候，我跑去湊熱鬧，看到有個攤上賣電腦雜誌，很厚很厚，每本才5角錢。每一期的厚度與現在的一般的小雜誌的合訂本差不多厚，我心想，這玩意買了可賺大了。那雜誌的名稱好像叫 個人電腦 吧，記不清了。不過，我還記得挺清楚，裡面有好幾篇文章是寫...
BCH壓力測試即將開始，你確定不來湊湊熱鬧？
bch壓力測試即將開始，你確定不來湊湊熱鬧？2018年5月15日，bch進行了新一輪的網路公升級，最為明顯的改變就是將區塊上限由之前的8mb調整至32mb，擴容的目的是為了提高bch網路的交易處理能力，讓bch區塊容量走到交易擁堵之前。在擴容之後，bch的交易量雖然在一直的增加，但距離填充32mb區...
我也來說說多核
究竟普通開發者是否需要面對多核，這個問題在很多地方都在討論。很多人都認為不需要，這樣說是基於過去幾年的經驗，認為目前的一般應用單核高速cpu已經足以應付，今後也沒有新的重要應用驅動我們使用多核cpu，多核cpu要麼是廠商狗急跳牆，要麼是僅供科研計算，謝絕參觀。看完myan的這篇，我也來說說 說多核無...