Table Modlue(Domain Logic Patterns)

概要
  • テーブル（ビュー）ごとにクラスを作成し、対応するテーブル（ビュー）の全行（実際は処理時に必要なある範囲の行だと思う）に対する処理を配置することで、ドメインロジックを分散配置するパターン。
  • Transaction ScriptとDomain Modelのあいのこのようなパターン。
  • Transaction Scriptと異なり、ドメインロジックはトランザクションごとに構成するのではなく、テーブルに関連づくクラス（Table Module）ごとに構成する。システムで必要な処理は、これらのクラス間の相互作用で実現する（Domain Model的）。
  • Table ModuleはDomain Modelと異なり、レコードごとにインスタンスをもたない。そもそもインスタンスを持たないか、テーブルごと（全レコード）に1つだけインスタンスを持つ（Transaction Script的）。
  • TableModuleがドメインロジックを実行する場合、大抵は対象レコードを指定するためのIDを受け取って動作する。
  • TableModuleを初期化するためのRecord Setは、自身の初期化時に自分で取得しても良いし、呼び出し側から渡されても良い。
  • 実際には、Table状データとみなされるものなら実テーブルでなくてもかまわない。
  • TableDataGatewayとの相性が良い。
  • DataTableを扱うLayer Supertypeを使ったりしてもよさそう。
メリット
  • DBとの親和性が高く、CRUD操作永続化のコストが低い。
  • それなりに意味のある単位でドメインロジックを分散管理できる。Transaction Scriptより重複コードを避けやすい。
デメリット
  • オブジェクト指向プログラミングの恩恵（継承関連）をフルには受けられない。
使いどころ
Record Setのようなデータ構造がUIから永続化まで幅広くサポートされている環境。要は、.NET環境。

参考リンク
実際にはどんな感じで適用しているのかいまひとつわかりづらかったけど、実際に適用された方がデブサミで発表＆QAで発言していました。
http://vsug.jp/tabid/63/forumid/72/postid/9190/view/topic/Default.aspx

コメント

コメントを投稿