數(shù)據(jù)持久技術(shù)
當(dāng)持久化興起的時候，逐漸形成了實(shí)體層這個概念了。hibernate,jdo,以及博客園的nbear都可謂是大名鼎鼎！有的公司不使用這種ORM框架,他們使用一些自動生成工具生成實(shí)體(例如用Codesmith生成)，并生成和該表對應(yīng)的業(yè)務(wù)邏輯，于是乎感覺我們的程序好像一下子全都寫好了，下一步就輕松了，我們只要擴(kuò)展業(yè)務(wù)即可了!莫非這樣真是那么方便了？在維護(hù)上真的是最便捷嗎？ 其它的持久層解決方案不敢說，但至少我覺得像orm的鼻祖hibernate那種開發(fā)機(jī)制,在維護(hù)還是相當(dāng)之麻煩呀！一個實(shí)體還得對應(yīng)一個xml文件（雖說這些都可以自動生成）,但是你深入項(xiàng)目的時候去想想，我們的業(yè)務(wù)真能一切都可以定下來嗎？人的思想總是在變的，客戶的需求就更難以著磨了！哪天我們要給程序加個字段，你想想你必須要走幾步改動？首先我們必須重新生成xml和實(shí)體，然后我們必須還得在業(yè)務(wù)邏輯中增加代碼，還得在視圖層加一個界面(如加一個input輸入框等)！講實(shí)話，加一個字段對這種orm框架的改動還是最少的，哪天假如說我們修改了哪個字段的名稱、修改了字段類型，你想想，天吶！很難想像，和這個字段關(guān)聯(lián)的程序都得改動!如果名稱改了，ok，你可以全部替換它的原先名稱，改成你新的名稱。那類型改了呢？沒辦法只能手工一個個改掉所有的賦值的類型吧？視圖層、控制層中的驗(yàn)證（js驗(yàn)證,業(yè)務(wù)驗(yàn)證）、邏輯層、實(shí)體層，xml配置等等都必須動。搞啥個hsq，這和sql不差不多了嗎（雖然說hsq，抽象了數(shù)據(jù)庫模型）？不過我想沒有程序員不懂sql的吧？況且hsq對復(fù)雜的語句還是會力不從心的吧！