在實際項目中，可能不同信任等級的數(shù)據(jù)，采用不同的算法去處理數(shù)據(jù)，這樣才使得數(shù)據(jù)的處理更有針對性，更符合實際需要。
從需求變更的角度出發(fā)，軟件開發(fā)商可以先實現(xiàn)一些數(shù)據(jù)信任程度低的算法，然后再根據(jù)項目實際情況，決定是否實現(xiàn)更高一級數(shù)據(jù)等級的算法。在現(xiàn)實軟件項目，數(shù)據(jù)信任等級低的采用的算法也會簡單一些，由于需求變更，增加了新的數(shù)據(jù)信任等級更高的數(shù)據(jù)，這時候可以考慮暫時采用低等級的算法進行處理，然后再結(jié)合人工干預，達到數(shù)據(jù)處理的要求。大家都明白一點，算法復雜，測試的難度大，但是使用這些更高等級的算法的幾率是很少的，處于成本的原因可以把這些算法的實現(xiàn)滯后。
當然我這樣說，并不是意味著放棄高等級的算法，一些根據(jù)項目實際情形需要來操作。
數(shù)據(jù)根據(jù)信任程度分成等級，呵呵，這是所謂工廠方法模式嘛，算法也分成等級結(jié)構(gòu)，這是所謂的模板方法模式。
數(shù)據(jù)在處理后，應該記錄下被使用的算法版本，這樣才便于以后統(tǒng)計查詢分析或者數(shù)據(jù)挖掘之類工作的開展。
例如：在一個商品交易中，一個商品可能被購買的價格是正常價格，節(jié)假日優(yōu)惠價，會員優(yōu)惠價，在交易流水賬中，應該記錄下交易時候是采用的那個價格類型，原始價格多少，實際購買價格多少。記錄下原始價格，是因為，商品的原始價格本身可能是變化的。
再以拆遷資源計劃系統(tǒng)(http://www.netsky-tech.com/))為例，房屋補償?shù)膬r格價格可能是來自于管理參數(shù)，也可能是來自于申請，實際到底是來自于哪個，算法應該記錄下來。
9.業(yè)務規(guī)則使用的版本化
前面已經(jīng)提到了數(shù)據(jù)錄入的版本化，還有算法的版本化，也是計算結(jié)果的版本化。但是還沒有談到一點，到底啥時間該采用哪個版本算法。
在J2EE項目中，一般是采用配置文件的方式來控制版本。從配置管理角度的來說，一切都根據(jù)配置文件來決定使用哪個版本的數(shù)據(jù)錄入的分級(數(shù)據(jù)信任程度分級)，然后根據(jù)配置文件決定數(shù)據(jù)處理使用的算法版本。
其實在J2EE項目中，可以采用類似apache commons-validator這樣的包，來進行數(shù)據(jù)錄入的信任等級建立。
前面都已經(jīng)提到了從工廠方法模式的角度來建立數(shù)據(jù)信任等級制度，但是并沒有解決到底啥時間采用哪個方法處理數(shù)據(jù)。也許有人建議，采用工廠方法模式的思想，把數(shù)據(jù)當成產(chǎn)品，把算法當成工廠，來處理（注意：不是制造）數(shù)據(jù)。這個想法也許能夠滿足一些系統(tǒng)的需要，但是更多時候是失效。
為此，我覺得有必要把算法的分配使用當成為一個業(yè)務管理策略來管理，通過單獨的業(yè)務模塊去設置業(yè)務的算法管理策略，可以把這些策略保存為配置文件或者直接保存到數(shù)據(jù)表；在J2EE項目中，常用的方式使用XML的格式保存為配置文件，但是如果這個策略比較復雜的時候建議還是保存到數(shù)據(jù)表。
參考UML圖
10.補充說明
由于近事情比較多，對于項目實施中的數(shù)據(jù)管理先整理這些，有空的話，再繼續(xù)整理。大家如果有興趣，可以切磋交流一下。
