今天你持久化了嗎？

   當持久化興起的時候，逐漸形成了實體層這個概念了。hibernate,jdo,以及部落格園的nbear都可謂是大名鼎鼎！有的公司不使用這種ORM架構,他們使用一些自動生成工具生成實體(例如用Codesmith生成)，并生成和該表對應的業務邏輯，于是乎感覺我們的程式好像一下子全都寫好了，下一步就輕松了，我們隻要擴充業務即可了!莫非這樣真是那麼友善了？在維護上真的是最便捷嗎？

     其它的持久層解決方案不敢說，但至少我覺得像orm的鼻祖hibernate那種開發機制,在維護還是相當之麻煩呀！一個實體還得對應一個xml檔案（雖說這些都可以自動生成）,但是你深入項目的時候去想想，我們的業務真能一切都可以定下來嗎？人的思想總是在變的，客戶的需求就更難以着磨了！哪天我們要給程式加個字段，你想想你必須要走幾步改動？首先我們必須重新生成xml和實體，然後我們必須還得在業務邏輯中增加代碼，還得在視圖層加一個界面(如加一個input輸入框等)！講實話，加一個字段對這種orm架構的改動還是最少的，哪天假如說我們修改了哪個字段的名稱、修改了字段類型，你想想，天呐！很難想像，和這個字段關聯的程式都得改動!如果名稱改了，ok，你可以全部替換它的原先名稱，改成你新的名稱。那類型改了呢？沒辦法隻能手工一個個改掉所有的指派的類型吧？視圖層、控制層中的驗證（js驗證,業務驗證）、邏輯層、實體層，xml配置等等都必須動。搞啥個hsq，這和sql不差不多了嗎（雖然說hsq，抽象了資料庫模型）？不過我想沒有程式員不懂sql的吧？況且hsq對複雜的語句還是會力不從心的吧！

     運用ORM架構勢必會運用大量的反射，代價是犧牲性能。當然現在的各種ORM架構都在嘗試使用各種方法來減輕這塊（LazyLoad，Cache），效果還是很顯著的。可是我們犧牲了這麼大的性能，而且我是覺得在維護上ORM還是最便捷。

      真不知道為啥像hibernate這樣的架構還有一個xml配置檔案？如果我真ORM的話，我不能把這些資料關系緩存起來，動态取關系不就行了嗎？這樣我不更靈活了嗎？

     當然使用ORM也有它的活的活之處，在維護上那種自動生成的方式(petshop模式)比使用ORM架構維護量上更大一些，那種構架如果是每個資料操作對應一個存儲過程的改動會更會讓人暈頭轉向的。其構架大緻如以下描述：

     主要由BLL,MODEL,DAL三層構架方式實作，BLL存放的是相關業務，MODEL是相關的資料庫表格實體，DAL業務的SQL語句（或存儲過程參數）.為了松散耦合，在BLL層和DAL層中間加入了工廠層(Factory)，其作用是友善DAL層的載體變動(如把Sqlserver改成Mysql),在DAL層有一個setObject資料庫字段到實體屬性設定,便于資料庫表格映射成實體。

     程式編寫的最大問題就是耦合高，怎麼降耦也是開發的一個重中之重。以上述的程式構架來看，如果我改動了資料庫中的其中一個表格的某個字段，程式改動的至少就有三層。如果再按照自動生成方式那種看，DAL中的update,insert,select, setObject都需要改動，如果存在存儲過程的話，像get,getAll,update,insert都必須改動，想象一下這裡改動地方有幾處了？而且還需改動Model層，修改量之大可見一斑。當然我們這裡可以用自動生成工具生成并替換，可又有誰知道這裡面的替換工作量多少?

     總之，提倡"高内聚，低耦合"是構架永恒的話題，尋找便捷亦是構架的終級目标。

 待續（下步講講我的開發架構）

本文轉自 netcorner 部落格園部落格，原文連結：  http://www.cnblogs.com/netcorner/archive/2008/07/21/1247461.html ，如需轉載請自行聯系原作者