最近做專案，有乙個星期的時間，都在跟同事討論：持久層怎麼辦？
是自己搞，還是用個持久層框架？
最後決定還是自己搞吧。
因為資料庫結構一直都在變，用了持久層的確不方便。
雖然，從某種程度上來講，持久層的確能減少**量。
更重要的是，資料庫已關係（表）為處理單元，而程式是以物件為單元。
因此，這種物件與關係的對映是很有必要的。
現在，突然覺得——持久層是軟體開發的乙個瓶頸。
如果沒有持久層，那麼軟體**量會增加，資料庫 dml 操作會變得極為不方便。
可如果有了，好像也不行。
一是持久層框架增加了軟體的複雜度，無法保證軟體執行的效率；
二是資料庫結構的變化對持久層的影響簡直是噩夢。
所以，對持久層框架的使用應該是慎重的。
特別是，在乙個專案，資料庫頻繁變更時。
比如，乙個企業，要做乙個軟體專案，之前什麼都沒有，沒資料庫，沒原型，一切從零開始。
這種情況下，誰敢用持久層呢。
但是如果軟體專案，僅僅是改造，或是在現有軟體的基礎上改版，或是借鑑現有軟體來重做。
這種情況下，倒是可以考慮選乙個持久層框架。
對需求的一點看法
需求是什麼，如何來做好需求，在cmmi 模型裡都給予了說明。模型將需求分為兩個部分，乙個是二級的需求管理，另乙個是 的需求開發 之後又看了rup 對需求的描述，它沒有明確對需求管理與開發進行劃分，它的工作流包括了以下幾個部分 問題分析，理解涉眾需要，定義系統，管理專案規模，改進系統定義，管理需求變更...
對教育的一點看法
百年大計，教育為本。這句話是誰說的，我就不說了，但是，什麼樣的教育是好的教育，什麼樣的人才是真正祖國需要的人才，什麼樣的教育模式才是真正好的教育模式，我作為乙個讀書讀了十多年的人，已經有了自己的看法，我想能看到我這篇博文的，都曾經有過乙個身份，那就是 學生 不論學歷是碩士 博士，還是本科專科，還是小...
對架構的一點看法
隨便想到點什麼就隨便寫寫，但是在實踐過程中，以下幾點真的很重要 關於架構 1.所有脫離業務的架構設計都是耍流氓 2.架構設計就是解決問題 權衡利弊的過程 3.權衡是架構逃避不掉的問題。可擴充套件性 業務方需求 效能 現狀 改變代價等的權衡 4.架構一定要有全域性觀 關於能力 1.相比於用過某個軟體某...