Page History
...
| Code Block |
|---|
SALARY NEP SALARY すなわち、 SALARYが以前のSALARYと等しくない すなわち、 SALARYが以前のSALARYと等しくない |
これにより、トリガーは、従業員のSALARYが変更された場合のみ、「UPDATE前」にアクティブ化されます。
...
| Code Block |
|---|
SALARY NEP SALARY
OR COMPANY NEP COMPANY
すなわち、
SALARYが以前のSALARYと等しくない
または COMPANYが以前のCOMPANYと等しくない |
...
この例には、優れたトリガーの設計と使用のために重要になる要素がいくつか示されています。
- 「カプセル化」原理。WEEKPAYを計算するための「具体的な処理」が、1つのファンクションに「カプセル化」されています。そのため、必要な変更を1箇所で行えます。「カプセル化」原理。WEEKPAYを計算するための「具体的な処理」が、1つのファンクションに「カプセル化」されています。そのため、必要な変更を1箇所で行えます。
- 必要が生じてからの設計。システム設計の初期段階では、WEEKPAYの具体的な処理の存在を定義する必要はありません。また、具体的な処理を想定して全体の設計を進める必要もありません。 逆に言うと、設計工程のどの時点でも、必要になった時点で具体的な中身を決めてよい、ということです。例えば、従業員を作成したり更新したりするアプリケーションが決まっていない段階で、WEEKPAYの具体的な処理を定義する必要はありません。まず、作成/更新アプリケーションを定義し、検査することができます。WEEKPAYの具体的な処理を作成、定義した時点から、既存のアプリケーションの処理に反映されるようになります。
- 再利用可能性。WEEKPAYを計算する具体的な処理は、従業員の詳細を作成または変更するアプリケーションによって自動的かつ暗黙的に再利用されます。トリガーは、通常のNPTデバイスから「従業員データ保守」ファンクションを通して、またはPCアプリケーションからLANSA Open機能を通してアクティブ化される可能性があります。
- 情報隠蔽。WEEKPAYというロジックが存在し、使用されているという事実は、「従業員データ保守」ファンクションを作成するRDMLビルダーからは見えません。また、RDMLビルダーにとっては意味がないものでしょう。
- 「具体的な処理」と「イベント」の分離。トリガー・ファンクションでは、「イベント」が発生したときに何を行うか(すなわち「具体的な処理」)を定義します。
ただし、イベントの発生を検出する必要はありません。
例えば、前に定義したファンクションでは、「週給の計算」という「具体的な処理」を定義しています。
業務上の規則では、新しい従業員が採用された場合、既存の従業員の給与が変更された場合、または既存の従業員が転職した場合に、週給を(再)計算しなければならないことを規定しています。
実際の「イベント」は、LANSAデータ・ディクショナリで定義します。