個版本算法。在J2EE項目中，一般是采用配置文件的方式來控制版本。從配置管理角度的來說，一切都根據(jù)配置文件來決定使用哪個版本的數(shù)據(jù)錄入的分級（數(shù)據(jù)信任程度分級），然后根據(jù)配置文件決定數(shù)據(jù)處理使用的算法版本。其實在J2EE項目中，可以采用類似apache commons-validator這樣的包，來進行數(shù)據(jù)錄入的信任等級建立。
前面都已經(jīng)提到了從工廠方法模式的角度來建立數(shù)據(jù)信任等級制度，但是并沒有解決到底啥時間采用哪個方法處理數(shù)據(jù)。也許有人建議，采用工廠方法模式的思想， 把數(shù)據(jù)當成產品，把算法當成工廠，來處理（注意：不是制造）數(shù)據(jù)。這個想法也許能夠滿足一些系統(tǒng)的需要，但是更多時候是失效。
3.算法的版本化
本來我打算在前面的基礎上，再談一下業(yè)務流程的管理設置問題，不過，現(xiàn)在工作流思想深入人心，我也就跳過了。我打算從數(shù)據(jù)的核心業(yè)務處理，算法處理角度來闡述。
其實在現(xiàn)實中的軟件項目中，大家提到的較多的BPR,工作流這些東西，但是很少提到算法這個單詞。當然，不可否認，很多軟件項目，特別是電子政務/OA的 業(yè)務主要是體現(xiàn)在流程/文件上，算法這部分比較簡單（當然，我這樣說，有人可能不認可，暫且就不爭論它了），就沒有必要去強調算法的重要性了。
為了避免垃圾數(shù)據(jù)進入系統(tǒng)，垃圾數(shù)據(jù)出來，有必要對數(shù)據(jù)進行分類管理。正如前面提到的那樣，對于進入系統(tǒng)的數(shù)據(jù)，進行信任等級劃分，數(shù)據(jù)來源的分類；但是 對于系統(tǒng)出口，為了避免出現(xiàn)垃圾數(shù)據(jù)，需要在數(shù)據(jù)處理階段，也要進行分類處理，這里就引入了算法的版本化，來適應不同的數(shù)據(jù)/業(yè)務需要。
在實際項目中，可能不同信任等級的數(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ù)，這時候可以考慮暫時采用低等級的算法進行處理，然后再結合人 工干預，達到數(shù)據(jù)處理的要求。大家都明白一點，算法復雜，測試的難度就大，但是使用這些更高等級的算法的幾率是很少的，處于成本的原因可以把這些算法的實 現(xiàn)滯后。
當然我這樣說，并不是意味著放棄高等級的算法，一些根據(jù)項目實際情形需要來操作。
數(shù)據(jù)根據(jù)信任程度分成等級，呵呵，這就是所謂工廠方法模式嘛，算法也分成等級結構，這就是所謂的模板方法模式。數(shù)據(jù)在處理后，應該記錄下被使用的算法版本，這樣才便于以后統(tǒng)計查詢分析或者數(shù)據(jù)挖掘之類工作的開展。
例如：在一個商品交易中，一個商品可能被購買的價格是正常價格，節(jié)假日優(yōu)惠價，會員優(yōu)惠價，在交易流水賬中，應該記錄下交易時候是采用的那個價格類型，原始價格多少，實際購買價格多少。記錄下原始價格，是因為，商品的原始價格本身可能是變化的。
再以拆遷資源計劃系統(tǒng)（http://www.netsky-tech.com/））為例，房屋補償?shù)膬r格價格可能是來自于管理參數(shù)，也可能是來自于申請，實際到底是來自于哪個，算法應該記錄下來。
為此，我覺得有必要把算法的分配使用當成為一個業(yè)務管理策略來管理，通過單獨的業(yè)務模塊去設置業(yè)務的算法管理策略，可以把這些策略保存為配置文件或者直接保存到數(shù)據(jù)表；在J2EE項目中，常用的方式使用XML的格式保存為配置文件，但是如果這個策略比較復雜的時候建議還是保存到數(shù)據(jù)表。