ERP程式開發中遇到的六種錯誤

經常回顧同事寫的**，發現一些問題，總結分析，用於員工培訓，或系統優化方面的內容教學。

文中有問題的的**我用黑體字標識。

1 介面與邏輯**混淆

這是目前發現的比較嚴重的問題。框架花費了很大的力氣，運用資料繫結，就是為了讓介面(控制項操作)與後台邏輯(驗證與傳值)執行相對嚴格的分離。這裡我只能說相對嚴格的分離，因為後台中一些操作不可避免的需要在前台提示使用者確認，或是提示使用者輸入一些變數值，這部分邏輯也可能會參與在前台介面中。我舉例如下。

private

void grid_aftercellupdate(object sender, celleventargs e)
}}

1 aftercellupdate事件完全可以放到後台業務邏輯類中，因為這裡只是做業務操作操作，並不涉及到使用者確認或輸入資料或使用者通知的行為，可以歸納的說，除了這三種特殊型別的操作之外(使用者確認，輸入資料，使用者通知)的資料變更，都可以放置到後台業務實體中完成。

2 效能：這裡經過了多次資料轉化呼叫(as操作符)，它的效能不太好。而且列名的判斷太遲，每次對grid的單元格的操作都會觸發兩次資料轉化(as操作符)行為。

這類xx_changed,xx_updated，盡量將**遷移到後台邏輯中。一是為了維護，二是改善效能。

2  事件的不恰當運用

closing事件是正在關閉時發生，還沒有關閉，這時可以取消，阻止事件冒泡。closed是關閉完成，可以做一些其它的資源釋放操作。理解這兩個事件的區別，有助於合理應用事件。參考下面的**

private

void chbsuspended_checkedchanged(object sender, eventargs e)
}

從**的意圖中我們可以看出，這是乙個需要使用者確認的操作。當使用者勾菜單選框之後，讀取資料判斷是否合理，提示使用者之後將單選框取消選擇。在這裡，我們完全可以把操作放到validating事件或是changing事件中，表達這個值改變之前還需要我們的驗證確認，這樣對系統的效能開銷比較小。如果如上**所示，等到值改變完成，控制項重新整理完成之後，再把它還原到未改變之前的狀態，這樣的效能不好。

簡單的說，就是把值提前計算好並儲存起來，在用的時候直接讀取值以取代頻繁的計算。這種情況出現的機率對高，我做幾處說明。

1）主表與從表的關係資料。主表需要儲存從表的資料統計。比如銷售訂單表頭有乙個amount金額字段用於儲存明細行的金額累總，這就是乙個典型的空間換時間的方案。因為讀取表頭的字段發生的頻率太高了，所以我們不會每次都讀取明細行並累總顯示。

2）基礎資料表與業務表的資料。比如，我要統計某乙個商品的採購訂單數量累總，銷售訂單數量累總，生產任務單數量累總。我們常用的方法是，要用到這些累總時，直接去讀取單據資料。而我這裡推薦的是空間換時間的方案。做單據業務時，將業務單據的資料提前儲存到基礎資料表中。再具體來說，就是qty_on_order(商品銷售訂單數量),qty_on_jo(商品生產訂單數量)等累總欄位增加到物料表中，在做業務單據時更新物料表相應欄位的值。

3）業務資料表的分析表。比如我們銷售送貨單，會建立兩張表（shipment/shipmentdetail）記錄此資料。為此，我們還需要提供大量的查詢以滿足各種業務場景。這時就可以考慮將建立新的資料表來儲存相關的查詢結果，比如未送貨/未完成訂單，需要綜合訂單表或送貨表來多緯度的查詢，按客戶，按銷售員，按專案等。這個專案中，會產生比較多的balance,journal,summary等資料表。

對於一些不常改變的資料項，在實施階段就固定下來的基礎資料，我們可以考慮在系統登入前快取到系統資料字典中，這樣在讀取資料時可顯示改善效率。一些常有的基礎資料，比如單位，貨幣，銷售員，會計帳戶，考慮將它們加入到系統快取中。如使用者更改這些資料項，需要更新快取中的資料項。

缺少了這項考慮，系統就會出現頻繁的從各個基礎資料表中讀取資料，給系統的效率帶來負擔。

對於數量單價類的字段值，它是直接從使用者介面中獲取，而對於平均單價，最後一次進倉單價，它們的值由系統計算得出。這就會造成前者與後者資料的產生時機不一致，兩者為空值null的情況會比較多。於是下面的查詢過濾條件常常是沒有作用的。

irelationpredicatebucket bucket=...

bucket.predicateexpression.add(salesorderdetailfields.qty > salesorderdetailfields.deliveryqty);

6 啟動窗體時載入資料項過多

盡量使用延遲載入資料的模式，而避免啟動介面時及時載入所有的資料項。這條規則比較明顯的地方是介面中有過多的dropdownlist或combobox。如果確定要使用這類控制項，應該將它的資料項載入時間延遲到控制項展開時完成(資料繫結優於逐個資料項增加)。參考這裡(

IT專案管理的六種錯誤思維

it專案管理的六種錯誤思維 錯誤一 錯誤的需求調研階段，導致很多專案永遠無法結束 在軟體行業，在介面設計沒有正式展現給客戶之前，所有的工作都處於需求調研階段。其實建築行業已經給我們做好了先例 客戶買房子之前是先要看看樣板房和模型的，什麼都看不到這房子你敢買麼?除非你不是自己住 而在我們所學的軟體工程...

創業者失去客戶的六種錯誤

著名的營銷專家joe girard曾寫過一本書 如何將任何東西賣給任何人 他說 你所遇到的每乙個人都有可能為你帶來至少250個潛在的顧客。這對想開展自己事業的人們可是個再好不過的訊息了。不過，根據joe girard的理論，從反面來看，當乙個顧客由於不滿意而離你而去時，你失去的不僅僅是乙個顧客，你將...

程式設計師的六種境界 摘抄

五流程式設計師比技術和工具 五流程式設計師關心的是用什麼工具可以產生什麼結果，追逐他聽過最新 最好 最時髦的技術，沉浸於一些小的練習，卻很少走出象牙塔和客戶或市場進行真正的溝通，甚至完成大型的真實案例。四流程式設計師比整合和管理 四流程式設計師比前者更關心在什麼地方使用什麼，他的心裡放著整合各種技術...