使用XML文件作為Web持久層的OO分析過程

在一個Web系統中有這樣的需求,一個頁面需要對一個XML文件進行CRUD等操作,如何設計一個系統適合這樣的需求呢?

最容易直接想到的是一個類完成節點的CRUD及IO操作,但這違反了類的設計原則--類應當只有一個中心任務.

所以按功能來分我們必須要兩個類:

一個類負責節點CRUD操作;// 簡稱CrudClass

一個類負責節點的IO操作;// 簡稱IoClass

這樣基本可以了,再細分下去沒有必要.

再來看第一個類,它是直接與一批業務代碼打交道的,首先要求速度要快,如果把解析出來的Dom放在類里,一則CrudClass做了IoClass做的事,二再速度上也上不去,所以這里我把dom里面的節點對應成了一個鏈表,一個值和一個Map,業務代碼實際處理的就是這三個東西,他們不關心也不必要知道是否存儲到了文件里,而且速度上得到了充分保證.

其次各個業務代碼處理的是同一事務,這里再把CrudClass做成單例(Singleton)形式的,做成全靜態也可以,但這種做法不太上臺面.

IoClass是CrudClass的持久化操作,他們之間實際是倉庫管理員和物流調度間的關系,這種關系有以下三種實現方式:

1.在他們間實現觀察者模式,由IoClass來觀察CrudClass,變化后寫入文件.初看這種方式很好的完成了解偶,實際上IoClass還是需要知道CrudClass的細節,否則無法更新,而且創建IoClass的過程比較麻煩,客觀世界可沒有這樣的處理.所以說觀察者處理當拋棄.

2.將IoClass作為CrudClass的成員,這種方式避免了IoClass創建的不必要的復雜過程,而且CrudClass知道IoClass的處理接口就行了,IoClass無需知道CrudClass的任何部分,實現了有效解偶,其三符合現實世界,IoClass確實應該是CrudClass的下級,只接受CrudClass指派的任務而外界無須知道IoClass,完全不必知道.

3.將IoClass獨立處理出來,與CrudClass等做成JMS異步通信方式或WebService通信方式,這個想法更OO,但是成本比較高,復雜度大,在大型系統可以考慮實現這種方案.

綜合上面的意見,選擇方案2是最適合的.

至此對一個XML文件進行CRUD操作的系統設計完成,再適當剝離一些通用代碼形成實用類就差不多了,這里不再贅述.

還是那句老話,道法自然.程序實現可以有N種實現方式,我們應該選擇最符合自然的一種.

（責任編輯：龔勛）

原文轉自：http://www.anti-gravitydesign.com