Lv. 2 : トリガフレームワークを導入してみよう
だんだんロジックが複雑になってきました。 また、同じコードが重複して存在している部分も気になりますね。 このまま続けても良いのですが、そろそろ本題に入りましょう。
Apex トリガの柔軟性・可読性を高めるフレームワークを導入することで何が嬉しいのかを実戦で学んでいきます。
ビジネス要件
- 将来的にシステムへの変更要求が頻繁に発生することが予想されています。既存のビジネスロジックを保ちながら、新規のビジネスロジックを追加しやすく、テストもしやすい設計方針へ改めてください。
アーキテクチャ要件
- Flexible Apex Trigger を利用してください。
- Apex トリガ内のビジネスロジックはすべて削除し、代わりに Apex クラスで実装してください。
- カスタムメタデータ型を利用して各 Apex クラスの有効化・無効化を制御できるようにしてください。
システム要件
Apex トリガ
| トリガ名 | 対象オブジェクト | 複数件レコードの一括処理 | 備考 |
|---|---|---|---|
AccountTrigger
|
取引先 | Yes | - |
Apex クラス
| クラス修飾子 | クラス名 | 継承 | 備考 |
|---|---|---|---|
public with sharing
|
AccountTriggerService
|
FAT_ITriggerObserver
|
- |
AccountTriggerService
| アクセス修飾子と型 | メソッド名 | 説明 | 備考 |
|---|---|---|---|
private void
|
addPrefixToName
|
(1) 項目自動更新 |
@TestVisible
|
private void
|
setCustomerPriority
|
(2) 項目自動更新 |
@TestVisible
|
-
新規作成する前に
addPrefixToNameおよびsetCustomerPriorityを実行する -
更新する前に
setCustomerPriorityを実行する
カスタムメタデータ型
FAT_TriggerObserver
|
表示ラベル カスタムメタデータレコード名 Apex Class |
sObject | Active | Before Insert |
Before Update |
Before Delete |
After Insert |
|---|---|---|---|---|---|---|
AccountTriggerService
|
Account |
Yes | Yes | Yes | No | No |