ERP程序开发中遇到的六种错误

常常回顾同事写的代码，发现一些问题，总结分析，用于员工培训，或系统优化方面的内容教学。

文中有问题的的代码我用黑体字标识。

1 界面与逻辑代码混淆

这是目前发现的比较严重的问题。框架花费了很大的力气，运用数据绑定，就是为了让界面(控件操做)与后台逻辑(验证与传值)执行相对严格的分离。这里我只能说相对严格的分离，由于后台中一些操做不可避免的须要在前台提示用户确认，或是提示用户输入一些变量值，这部分逻辑也可能会参与在前台界面中。我举例以下。

private void grid_AfterCellUpdate(object sender, CellEventArgs e)
{         
            if (this.gridUom.ActiveCell == null || !this.gridUom.ActiveCell.IsDataCell)
                return;

            ItemEntity Ientity = itemBindingSource.Current as ItemEntity;
            ItemAuxiLiaryEntity itemAuxiLiaryEntity = gridUom.GetRowListObject(gridUom.ActiveRow) as ItemAuxiLiaryEntity;
            if (gridUom.ActiveRow != null)
            {
                if (BaseCommon.StringCompare(e.Cell.Column.Key, "AuxiLiaryDefault") == 0)
                {
                   
                    List<int> indices = entity.ItemAuxiLiaries.FindMatches(ItemAuxiLiaryFields.AuxiLiaryDefault == true & ItemAuxiLiaryFields.Uom != itemAuxiLiaryEntity.Uom);
                    if (indices.Count > 0)
                    {
                        ItemAuxiLiaryEntity customerEntity = entity.ItemAuxiLiaries[indices[0]] as ItemAuxiLiaryEntity;
                        customerEntity.AuxiLiaryDefault = false;
                     }
             }
}

这段代码有如下几个问题

1 AfterCellUpdate事件彻底能够放到后台业务逻辑类中，由于这里只是作业务操做操做，并不涉及到用户确认或输入数据或用户通知的行为，能够概括的说，除了这三种特殊类型的操做以外(用户确认，输入数据，用户通知)的数据变动，均可以放置到后台业务实体中完成。

2 性能：这里通过了屡次数据转化调用(as操做符)，它的性能不太好。并且列名的判断太迟，每次对Grid的单元格的操做都会触发两次数据转化(as操做符)行为。

这类XX_Changed,XX_Updated，尽可能将代码迁移到后台逻辑中。一是为了维护，二是改善性能。

2  事件的不恰当运用

Closing事件是正在关闭时发生，尚未关闭，这时能够取消，阻止事件冒泡。Closed是关闭完成，能够作一些其它的资源释放操做。理解这两个事件的区别，有助于合理应用事件。参考下面的代码

private void chbSuspended_CheckedChanged(object sender, EventArgs e)
 {
            if (chbSuspended.Checked)
            {
                if (!string.IsNullOrEmpty(txtItemNo.Text))
                {
                   
                    IPurchaseOrderManager PurchaseOrderManager = ClientProxyFactory.CreateProxyInstance<IPurchaseOrderManager>();
                    if (PurchaseOrderManager.IsPurchaseOrderExist(bucket))
                    {
                        DialogResult Result = BaseCommon.ShowConfirm("Item is already in used", null, MessageBoxButtons.OKCancel);
                        if (Result != DialogResult.OK)
                        {
                            chbSuspended.Checked = false;
                        }
                    }

从代码的意图中咱们能够看出，这是一个须要用户确认的操做。当用户勾选单选框以后，读取数据判断是否合理，提示用户以后将单选框取消选择。在这里，咱们彻底能够把操做放到Validating事件或是Changing事件中，表达这个值改变以前还须要咱们的验证确认，这样对系统的性能开销比较小。若是如上代码所示，等到值改变完成，控件刷新完成以后，再把它还原到未改变以前的状态，这样的性能很差。

3 应该考虑用空间换时间的性能改善方案

简单的说，就是把值提早计算好并保存起来，在用的时候直接读取值以取代频繁的计算。这种状况出现的概率对高，我作几处说明。

1）主表与从表的关系数据。主表须要保存从表的数据统计。好比销售订单表头有一个Amount金额字段用于保存明细行的金额累总，这就是一个典型的空间换时间的方案。由于读取表头的字段发生的频率过高了，因此咱们不会每次都读取明细行并累总显示。

2）基础数据表与业务表的数据。好比，我要统计某一个商品的采购订单数量累总，销售订单数量累总，生产任务单数量累总。咱们经常使用的方法是，要用到这些累总时，直接去读取单据数据。而我这里推荐的是空间换时间的方案。作单据业务时，将业务单据的数据提早保存到基础数据表中。再具体来讲，就是qty_on_order(商品销售订单数量),qty_on_jo(商品生产订单数量)等累总字段增长到物料表中，在作业务单据时更新物料表相应字段的值。

3）业务数据表的分析表。好比咱们销售送货单，会建立两张表（Shipment/ShipmentDetail）记录此数据。为此，咱们还须要提供大量的查询以知足各类业务场景。这时就能够考虑将建立新的数据表来存储相关的查询结果，好比未送货/未完成订单，须要综合订单表或送货表来多纬度的查询，按客户，按销售员，按项目等。这个项目中，会产生比较多的Balance,Journal,Summary等数据表。

4 合理利用缓存可改善系统效率

对于一些不常改变的数据项，在实施阶段就固定下来的基础数据，咱们能够考虑在系统登入前缓存到系统数据字典中，这样在读取数据时可显示改善效率。一些常有的基础数据，好比单位，货币，销售员，会计账户，考虑将它们加入到系统缓存中。如用户更改这些数据项，须要更新缓存中的数据项。

缺乏了这项考虑，系统就会出现频繁的从各个基础数据表中读取数据，给系统的效率带来负担。

5 缺乏对数据库NULL值的处理

对于数量单价类的字段值，它是直接从用户界面中获取，而对于平均单价，最后一次进仓单价，它们的值由系统计算得出。这就会形成前者与后者数据的产生时机不一致，二者为空值NULL的状况会比较多。因而下面的查询过滤条件经常是没有做用的。

IRelationPredicateBucket bucket=...
bucket.PredicateExpression.Add(SalesOrderDetailFields.Qty > SalesOrderDetailFields.DeliveryQty);

对于字符串的字段，null和string.Empty是不一样的，在数据库中，NULL和空字符串也是不一样的。字符的全角半角也应该控制好。

6 启动窗体时载入数据项过多

尽可能使用延迟加载数据的模式，而避免启动界面时及时加载全部的数据项。这条规则比较明显的地方是界面中有过多的DropDownList或ComboBox。若是肯定要使用这类控件，应该将它的数据项载入时间延迟到控件展开时完成(数据绑定优于逐个数据项增长)。参考这里(http://stackoverflow.com/questions/2901371/lazy-loading-wpf-combobox-items)。