[デザインパターン／永続化]
平澤 章
Ver 0.1 - 1999/3/11
Ver 0.2 - 1999/8/23
ヘッダー−明細形式のオブジェクトの永続処理をシンプルな方式で実現する。
事務処理系アプリケーションでは、ヘッダー−明細形式で保持される情報がしばしば現れる。
（複数の商品をまとめて販売する場合に、売上と売上明細オブジェクトとして表現する場合など。）
このような情報をリレーショナルデータベース上に永続化する場合、通常はヘッダーと明細それぞれを格納するためのテーブルを用意して実装する。
このとき新規登録については大きな問題がないが、変更には次に挙げるようなさまざまなバリエーションがあり、さらにこれらが組み合わせられる場合もある。
ケース1) ヘッダーオブジェクトの属性だけが変更される場合。
ケース2) いくつかの明細オブジェクトの属性が変更される場合。
ケース3)
新たな明細オブジェクトが追加される場合。
ケース4) 既存の明細オブジェクトが削除される場合。
これを変更内容に即して忠実にSQLを発行しようとすると、次のようになる。
ケース1) ヘッダーレコードに対してUPDATE-SQLを発行する。
ケース2)
変更対象の明細レコードに対してUPDATE-SQLを発行する。
ケース3)
新しい明細レコードをINSERTする。
ケース4)
明細レコードを削除する。明細レコードが１からはじまる行番号で管理されている場合、削除された以降の行番号を繰り上げるため、UPDATE-SQLを発行する。
このように個別の変更内容に応じた永続処理をそのまま実装しようとすると、アプリケーションのロジックは非常に煩わしくなってしまう。
このような事態を改善するために、どのような変更の場合でも、いったんすべての明細レコードを削除し、その後に新しい明細レコードをINSERTする方法がある。
この方法によれば、変更の内容によらず同一のパターンで処理ができるため、アプリケーションロジックを単純にすることができる。
HEADER DETAILパターンは、次のような場合に適用できる。
ヘッダー−明細オブジェクトの登録は、ヘッダーと明細両方の属性情報の妥当性を検証する必要がある場合があるため、一意なタイミングにする必要がある。
したがってClientはヘッダーおよび明細オブジェクトを生成し、必要な情報を設定した後、ヘッダーオブジェクトにだけ登録要求(Storeメソッド)を発行する。明細オブジェクトへの登録要求は、ヘッダーオブジェクトが自動的に発行する。
変更の場合も新規登録の場合と同様に、ClientはHeaderDomainおよびDetailDomainオブジェクトを生成し、必要な属性情報を設定する。ただしこの場合Clientは、Restoreメソッドを発行することで、HeaderDomainオブジェクトに対して、更新要求であることを伝える。
この更新要求はHeaderPersisterとDetailPersisterがそれぞれ役割分担することで実現される。
省略
省略
某社会計システム
某社在庫＆販売管理システム