LLBL Gen 3.x 源代码追踪与解析 验证Validation的原理和流程

本文深入探讨了采购订单实体在不同操作阶段的验证机制,包括保存前、删除前及属性值变化后的验证流程,通过实例展示了如何实现这些验证逻辑。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

先看应用程序如何应用验证。以SalesOrderHeaderEntity为例子。
常见的三种验证:
1)保存之前的验证,重写ValidateEntityBeforeSave
2) 删除前的验证,重写ValidateEntityBeforeDelete
3) 属性获取值之后的验证,重写ValidateFieldValue

先讲解一个基本的模式,基类中的设计virtual方法,派生中中override,我们在运行时,会调用实际类型的方法
public class  A

   public virtual Do() {  }
}
public class B: A
{  
   public override Do() { }
}
当以这种方法调用时
A  obj=new B():

obj.Do();
它会根据obj的实际类型,调用对应的方法

 

验证代码的书写

[Serializable] 
public partial class SalesOrderHeaderValidator : ValidatorBase 

   // __LLBLGENPRO_USER_CODE_REGION_START ValidationCode 
   删除采购单前的验证,比如采购单还在被合同contact引用,则不允许删除 
  public override void ValidateEntityBeforeDelete(IEntityCore involvedEntity) 
   { 
         base.ValidateEntityBeforeDelete(involvedEntity); 
         SalesOrderHeaderEntity salesOrder = (SalesOrderHeaderEntity)involvedEntity; 
         if (salesOrder.TotalDue != 0) 
             throw new Exception("Total due zero not allow for this period");

    } 
   保存采购单前的验证,常常是验证必须输入值的字段

   public override void ValidateEntityBeforeSave(IEntityCore involvedEntity) 
   { 
          base.ValidateEntityBeforeSave(involvedEntity); 
          SalesOrderHeaderEntity salesOrder = (SalesOrderHeaderEntity)involvedEntity; 
          if(salesOrder.TaxAmt>1000)
                throw new Exception("unable to deal with tax more than 1000"); 
    }  
   采购单的属性值发生改变时,应用此处的验证,比如,当获取截止日期后,要验证它不能小于当前日期

  public override bool ValidateFieldValue(IEntityCore involvedEntity, int fieldIndex, object value) 
     {
            bool result = base.ValidateFieldValue(involvedEntity, fieldIndex, value);
            if (!result)
                return false;

            SalesOrderHeaderEntity salesOrder = (SalesOrderHeaderEntity)involvedEntity;

            switch ((SalesOrderHeaderFieldIndex)fieldIndex)
            {
                case SalesOrderHeaderFieldIndex.DueDate:
                       return ValidateDueDate(salesOrder, (DateTime)value);            
            }
            return true;
        }

        private bool ValidateDueDate(SalesOrderHeaderEntity salesOrder, DateTime value)
        {
            if(value.CompareTo(DateTime.Now) < 0)
                throw new Exception("Due date cannot be less than today");
            return true;
        }   
}

挂接到验证代码到实体中

重写OnInitialized方法,给Validator 属性指定验证器
protected override void OnInitialized()
{
       base.OnInitialized(); 
        //Assign validator
       this.Validator =new SalesOrderHeaderValidator();
}

追踪删除采购单的堆栈

先设计一个删除的采购单的测试方法

[TestMethod]
public void TestDeleteSalesOrderHeader()
{
         DataAccessAdapter adapter = new DataAccessAdapter(ConnectionString);
         SalesOrderHeaderEntity salesOrder = new SalesOrderHeaderEntity(43659);
         adapter.DeleteEntity(salesOrder);            
}

进入DataAccessAdapterBase的方法
public bool DeleteEntity(IEntity2 entityToDelete)
{
         return DeleteEntity(entityToDelete, null);
}

调用它的重载overload方法

public virtual bool DeleteEntity(IEntity2 entityToDelete, IPredicateExpression deleteRestriction)
{

       EntityBase2 entityToDeleteAsEntityBase2 = (EntityBase2)entityToDelete;
       entityToDeleteAsEntityBase2.CallValidateEntityBeforeDelete();
}

进入EntityBase2的CallValidateEntityBeforeDelete
internal void CallValidateEntityBeforeDelete()
{
       OnValidateEntityBeforeDelete();
}
继续进入OnValidateEntityBeforeDelete方法
protected virtual void OnValidateEntityBeforeDelete()
        {
            if( _validator != null )
            {
                _validator.ValidateEntityBeforeDelete( this );
            }
        }

至此就进入到了我在文章开头写的SalesOrderHeaderValidator的ValidateEntityBeforeDelete方法
再来看一下ValidatorBase 中的虚拟方法ValidateEntityBeforeDelete

[Serializable]
public abstract class ValidatorBase : IValidator
{

        public virtual void ValidateEntityBeforeDelete( IEntityCore involvedEntity )
        {
            // nop
        }


验证属性值

再来看属性设置时的验证,这种验证方法可以验证程序对采购单的任何属性的复制行为。比如,业务规则是,任何时间,采购单的截止日期都不能小于输入采购单的当天,代码如下,
SalesOrderHeaderEntity salesOrder = new SalesOrderHeaderEntity(2068);
salesOrder.DueDate = DateTime.Now.AddDays(-1); //这里设置DueDate 的值为昨天,违反了业务规则
来追踪它的堆栈,进入DueDate属性的set方法

public virtual System.DateTime DueDate
        {
              set    { SetValue((int)SalesOrderHeaderFieldIndex.DueDate, value); }
        }

进入EntityBase2的SetValue方法
protected bool SetValue(int fieldIndex, object value)
        {
            return SetValue(fieldIndex, value, true);
        }

同名的重载方法

protected bool SetValue(int fieldIndex, object value, bool performDesyncForFKFields)
        {

            // set value is not the same as the value to set, proceed
            if(ValidateValue(fieldToSet, ref valueToSet, fieldIndex))
进入ValidateValue方法

private bool ValidateValue(IFieldInfo fieldToValidate, ref object value, int fieldIndex)
        {
               // perform custom validation.
                validationResult = (OnValidateFieldValue(fieldIndex, value));

          }
流程进入OnValidateFieldValue方法

protected virtual bool OnValidateFieldValue( int fieldIndex, object value )
        {
            bool returnValue = true;
            if( _validator != null )
            {
                returnValue = _validator.ValidateFieldValue(this, fieldIndex, value );
            }
            return returnValue;
        }

请注意看这一句returnValue = _validator.ValidateFieldValue(this, fieldIndex, value ),它会进入我在开头重写的ValidateFieldValue的方法里面,最后就是进入自定义的方法ValidateDueDate

image

这就是验证的完整堆栈流程。

标题基于SpringBoot+Vue的学生交流互助平台研究AI更换标题第1章引言介绍学生交流互助平台的研究背景、意义、现状、方法创新点。1.1研究背景意义分析学生交流互助平台在当前教育环境下的需求及其重要性。1.2国内外研究现状综述国内外在学生交流互助平台方面的研究进展实践应用。1.3研究方法创新点概述本研究采用的方法论、技术路线及预期的创新成果。第2章相关理论阐述SpringBootVue框架的理论基础及在学生交流互助平台中的应用。2.1SpringBoot框架概述介绍SpringBoot框架的核心思想、特点及优势。2.2Vue框架概述阐述Vue框架的基本原理、组件化开发思想及前端的交互机制。2.3SpringBootVue的整合应用探讨SpringBootVue在学生交流互助平台中的整合方式及优势。第3章平台需求分析深入分析学生交流互助平台的功能需求、非功能需求及用户体验要求。3.1功能需求分析详细阐述平台的各项功能需求,如用户管理、信息交流、互助学习等。3.2非功能需求分析对平台的性能、安全性、可扩展性等非功能需求进行分析。3.3用户体验要求从用户角度出发,提出平台在易用性、美观性等方面的要求。第4章平台设计实现具体描述学生交流互助平台的架构设计、功能实现及前后端交互细节。4.1平台架构设计给出平台的整体架构设计,包括前后端分离、微服务架构等思想的应用。4.2功能模块实现详细阐述各个功能模块的实现过程,如用户登录注册、信息发布查看、在线交流等。4.3前后端交互细节介绍前后端数据交互的方式、接口设计及数据传输过程中的安全问题。第5章平台测试优化对平台进行全面的测试,发现并解决潜在问题,同时进行优化以提高性能。5.1测试环境方案介绍测试环境的搭建及所采用的测试方案,包括单元测试、集成测试等。5.2测试结果分析对测试结果进行详细分析,找出问题的根源并
内容概要:本文详细介绍了一个基于灰狼优化算法(GWO)优化的卷积双向长短期记忆神经网络(CNN-BiLSTM)融合注意力机制的多变量多步时间序列预测项目。该项目旨在解决传统时序预测方法难以捕捉非线性、复杂时序依赖关系的问题,通过融合CNN的空间特征提取、BiLSTM的时序建模能力及注意力机制的动态权重调节能力,实现对多变量多步时间序列的精准预测。项目不仅涵盖了数据预处理、模型构建训练、性能评估,还包括了GUI界面的设计实现。此外,文章还讨论了模型的部署、应用领域及其未来改进方向。 适合人群:具备一定编程基础,特别是对深度学习、时间序列预测及优化算法有一定了解的研发人员数据科学家。 使用场景及目标:①用于智能电网负荷预测、金融市场多资产价格预测、环境气象多参数预报、智能制造设备状态监测预测维护、交通流量预测智慧交通管理、医疗健康多指标预测等领域;②提升多变量多步时间序列预测精度,优化资源调度风险管控;③实现自动化超参数优化,降低人工调参成本,提高模型训练效率;④增强模型对复杂时序数据特征的学习能力,促进智能决策支持应用。 阅读建议:此资源不仅提供了详细的代码实现模型架构解析,还深入探讨了模型优化实际应用中的挑战解决方案。因此,在学习过程中,建议结合理论实践,逐步理解各个模块的功能实现细节,并尝试在自己的项目中应用这些技术方法。同时,注意数据预处理的重要性,合理设置模型参数网络结构,控制多步预测误差传播,防范过拟合,规划计算资源训练时间,关注模型的可解释性透明度,以及持续更新迭代模型,以适应数据分布的变化。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值