复杂业务简单化的一个小技巧

在复杂系统中，当对业务数据进行“删除”时(一般不允许对业务数据进行删除，只是举例) ，需要根据其它业务数据进行判断如：

　　1.已生成出库单不允许删除，

　　2.付款单已确认不允许删除，

　　3.已经退换货则不允许删除。

　　实际业务中可能会更加复杂。

      当出现这种情况时将导致“删除”业务判断会非常多，而且会经常修改，很有可能当其它业务发生变化时需要重新去调整“删除”业务。

解决方法：为业务数据增加一个中间件“是否可以删除的标识”其它业务发生变化时修改此标识为false  其它业务修改时不能将此标识改为true 删除时只根据此标识做判断，可能会手动修改业务标识（高级操作）

      不能将此标识改为true是因为 改为true需要去做很多验证，为了避免复杂性所以不能修改标识为true。

      如：用户提出需求“自营店，可以修改价格，可以添加赠品，不扣预存款。非自营店，不能改价格，不能加赠品，扣款存款”

            程序设计时最好别把 “自营或非自营”做为判断条件，而将“是否允许修改价格，是否允许添加赠品，是否扣除预存款”做为判断条件，对店铺(业务数据)增加相应的控制开关配置。

            这样可能很好的提高程序扩展性，未来业务发生变化时可以不用修改代码。比如 需要"非自营店可能添加赠品"时。

     对业务数据的控制开关配置可以使用key/value形式通一设计持久化保存，这些开关拒绝和业务数据的查询有联系。

     注意事项：1.如果系统中大量使用开关配置，会经常会开关配置进行修改，需要考虑并发性，防止多个业务同时对相同的控制开发进行修改。

                   2.此类配置不会做为数据检索条件

    

    以上是工作中记录内容，分享相应的处理代码，希望对你们有用

 

/// <summary>
    /// 数据配置类
    /// </summary>
    public class SmartConfig : BaseEntity
    {
        /// <summary>
        /// 类型
        /// </summary>
        [MaxLength(32)]
        public string Type { get; set; }
        /// <summary>
        /// 类型标识
        /// </summary>
        [MaxLength(32)]
        public string TypeIdentity { get; set; }
        /// <summary>
        /// 时间截
        /// </summary>
        [MaxLength(32)]
        public string Timestamp { get; set; }
        /// <summary>
        /// 配置
        /// </summary>
        public string Config { get; set; }
    }

View Code

这是Table对应的实体类,用于数据存储。