実装ガイド › ケース スタディ例 › 効果的なビジネス ロジック例の作成

効果的なビジネス ロジック例の作成

効果的なビジネス ロジックの書き方についてのベスト プラクティスの推奨が以下の項目として挙げられています。

• クラスタ化メトリック
  • システムのボリュームを評価するとき、クラスタ化メトリックをメトリック内の項目の数として数え、すべてがかけ算されることを覚えておきます。
  • 1 つのクラスタ アイテムの再計算は、クラスタ全体の再計算を意味します。 したがって、クラスタ化を検討するとき、アダプタが構成される方法およびリソース構造を変更するときはにはこの点を忘れずに考慮します。
  • 多くのクラスタ アイテムに移動する同じ Raw データ イベントには、高機能コスト（コンテキスト スイッチング）があります。
• グローバル変数
  • コード中の必要な場所それぞれでパラメータと属性値を取得します。 それらをグローバル変数、特にクラスタ化メトリックに保持するのは避けます（“states” サイズが増加します）
  • 大きなマップを処理するロジックは避けます。 代わりに、各イベントを OnXXEvent メソッドで処理します
  • マップからできるだけ早く項目を削除します。 たとえば、チケットが、期間の最後でないときに閉じられる場合
• デザイン パターン

  事前定義コンテンツ パッケージには、共通シナリオ用にいくつかのデザイン パターンが用意されています。 これらのデザイン パターンを使用するとパフォーマンスが改善する場合があります。

• ビルトイン機能

  ACE には以下のようなさまざまな目的のためのビルトイン機能とツールがあります。

  • 時間帯機能
    • NetTime
    • IsWithinTimeslot
  • イベントの時間
    • TimeOfLastEvent
    • TimeOfLastEventHandler
  • コンテキスト オブジェクト
    • 多くの環境に敏感なメソッドを含んでいます。
    • これらのメソッドを使用し、"安全な ODBC" を回避します。
• ビジネス ロジック出力

  T_SLALOM_OUTPUTS 内に構造を保持します。 これは、類似の構造を持つ T_SLALOM_OUTPUTS に論理テーブルをいくつか持っている場合、同じ物理フィールドに類似の論理フィールドを置くことは非常に役立つことを意味します。 これにより、インデックス付けが容易になりレポートのパフォーマンスが向上します。

• イベント再利用性

  使用するとき

  • いくつかのメトリックは第 1 フェーズの計算を実行中です。これ自体、契約に必要ですが、結果を計算する要約メトリックにイベントを送信します（たとえば会計計算、高レベル KPI）。
  • Raw データに予備集約を実行し、他のいくつかのメトリックにイベントを送信する単一のメトリック。 メトリックが、得たよりも相当に少ないイベントを送信するか、または何度も実行される重要な計算を実行する場合は合理的。

  避けるとき

  • メトリックの数を著しく増加させる場合
  • 3 レベルを超える実装
  • 実装の複雑さは増し、保守はさらに困難になります。
• 再計算
  • システムの通常動作の一部としての重い再計算を回避
  • 再計算の理由は次のとおりです。
    • 過去のタイム スタンプを備えた Raw データ
    • 過去の Raw データを変更するイベント固有性
    • 修正
    • 例外
    • ビジネス ロジック モジュールでの変更
    • 契約の変更
    • 過去のタイム スタンプを備えたイベント再利用性イベント
    • リソース構造体の変更
  • 計算されたデータのロック機能の使用検討
• ビジネス ロジック モジュール
  • ビジネス ロジック モジュールは、一度は完全に確認され、変更の必要がないという方法で書かれる必要があります。
  • ガイドラインは、1 つのモジュールは 1 つの一般的なロジックと等しい、というものです。
  • 非常に具体的なビジネス ロジック モジュールは多くのメトリックで利用できず、コードおよびロジックの再利用を促進しません。
  • 一般的すぎるビジネス ロジック モジュールは保守が困難です。 さらに、ビジネス ロジック モジュールが多くの複雑なロジックを実装している場合、（メトリックの一部によって使用された）1 つのフローで 1 箇所修正すると、すべてのメトリックを再計算することになります。
• 登録
  • 登録を使用して、イベントのフィルタリングをすべて実行します。 コードにフィルタリングを残すとパフォーマンスに大きく影響します
  • 単純化
  • 登録自体でないコードについては、特にリソース変更が多数あるときは、dispatcher.IsRunTimeMode と OnResourceStructureChange のメソッドを使用します
  • RegisterByEventType メソッド使用の回避
  • ビジネス ロジック モジュールでは、（契約関係者、サービス、リソース タイプによる）一般的な形式を使用するか、パラメータを使用するか、またはユーザ インターフェース（イベント再利用性用の優先オプション）を使用して実行される登録を残します。