实施指南 › 案例研究示例 › 编写生效的业务逻辑示例

编写生效的业务逻辑示例

从以下主题的角度，就如何编写生效的业务逻辑提供了一些最佳实践建议：

• 组群的度量标准
  • 在评估系统卷时，根据度量标准中的项数统计组群的度量标准，并记住所有内容都成倍增加。
  • 重新计算某个群项即意味着重新计算整个群。 因此，在规划组群和配置适配器的方式以及更改资源结构时，请记得考虑这一点
  • 转到多个群项的相同原始数据事件都具有很高的性能成本（上下文切换）
• 全局变量
  • 在代码中的每个位置上获取所需的参数和属性值。 避免在全局变量中保留这些值，尤其是在组群的度量标准中（这会增加“状态”的大小）
  • 避免用于处理大型映射的逻辑。 而是采用 OnXXEvent 方法处理每个事件
  • 尽快删除映射中的项。 例如，在关闭故障单时，而不是在期间结束时
• 设计模式

  预定义内容数据包包含适用于常见方案的多个设计模式。 使用这些设计模式可以改善性能

• 内置功能

  ACE 具有针对各种用途的内置功能和工具，如下所示：

  • 时间段功能
    • NetTime
    • IsWithinTimeslot
  • 事件时间
    • TimeOfLastEvent
    • TimeOfLastEventHandler
  • Context 对象
    • 包含多个环境敏感的方法
    • 使用这些方法并避免“安全 ODBC”
• 业务逻辑输出

  在 T_SLALOM_OUTPUTS 中保留结构。 这意味着，如果您在 T_SLALOM_OUTPUTS 中具有多个结构类似的逻辑表，则在同一物理字段中放置类似的逻辑字段将非常有用。 这样，可以轻松完成索引以改进报告性能

• 事件可重用性

  在以下情况下使用：

  • 多个度量标准正在执行第一阶段计算（这是合同本身所需要的），并将事件发送给用于计算结果的摘要度量标准（例如，财务计算、高级 KPI）
  • 单个度量标准正在对原始数据执行初始聚合，并将事件发送给多个其他度量标准。 在度量标准发送的事件明显少于所获得的事件或执行大量计算（而这些计算被多次执行）时，这将是合理的

  在以下情况下避免：

  • 度量标准数目显著增加
  • 实施超过三个级别
  • 实施复杂性增加且更难于维护
• 重新计算
  • 避免大规模重新计算成为系统正常运行的一部分
  • 重新计算的原因如下：
    • 过去带有时间戳的原始数据
    • 过去用于更改原始数据的事件单一性
    • 更正
    • 例外
    • 业务逻辑模块方面的更改
    • 合同方面的更改
    • 过去带有时间戳的事件重用性事件
    • 资源结构方面的更改
  • 考虑使用计算数据锁定功能
• 业务逻辑模块
  • 业务逻辑模块应在完全审查后无需更改的情况下写入
  • 准则为：一个模块等于一种常规逻辑
  • 非常具体的业务逻辑模块无法为多个度量标准提供服务，且不支持代码和逻辑重用性
  • 太常规化的业务逻辑模块难以维护。 此外，如果业务逻辑模块实施多个复杂逻辑，修复某个流（用于部分度量标准）将会导致重新计算所有度量标准
• 注册
  • 使用注册执行所有事件筛选。 将筛选保留给代码会对性能产生巨大影响
  • 使其简化
  • 对于本身不是注册的代码，请使用 dispatcher.IsRunTimeMode 和 OnResourceStructureChange 方法，尤其是存在多个资源更改时
  • 避免使用 RegisterByEventType 方法
  • 在业务逻辑模块中，使用常规表单（按合同方、服务、资源类型）或参数，或通过用户界面执行注册（实现事件可重用性的首选）