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