Metadata Mapping

Holds details of object-relational maping in metadata.

• O/Rマッピングのコードのほとんどは、フィールドの対応づけ

  • DBのテーブルのフィールド
  • メモリ上のオブジェクトのフィールド
• 退屈な繰り返しコードになる

• 本パターンでは、フィールドの対応表を定義して汎用コードで処理を実行する

  • read
  • insert
  • update

How It Works

• とるべき道は2つ

  • コード生成

    • メタデータを入力し、ソースコードを出力する
    • 手で書いたコードのように見える

    • 肝

      • ビルドプロセスに組み入れて、手で触られないことを保証する
      • VCS管理外におく

  • リフレクション

    • 【補】PHPでいうと__call()マジックメソッドがこれにあたる

• 著者はふだんリフレクション否定派

  • 遅い
  • デバッグしづらい

• だが、リフレクションはDBマッピングには好適

  • 柔軟性をいかんなく発揮できる
• 比較

• リフレクションでは、実行中にDBマッピング定義を更新することができる

• リフレクションの実行時速度は遅い

  • が、SQLのリモートコールに比較すれば大したことはない
  • 測定せよ

• デバッグのしやすさについては、開発者の慣れにもよる

  • コード生成は、生成後のコードにブレークポイントを張れる

• マッピング定義メタデータの置き場所？

  • 別ファイル

    • XMLとか
    • パース処理必要

  • ソースコード内に直書き

    • パース処理不要
    • 編集大変

  • DB自身に持たせる

    • DBのスキーマ定義が変化したら追従させる

• メタデータの置き場所が実行時パフォーマンスに与える影響は大抵無視できる

  • コード生成

    • メタデータに基づいてビルドを行うのはコンパイル前

      • 実行時オーバヘッドなし

  • リフレクション

    • メタデータ読み込みは実行時だが、プログラム起動時一度だけ

• メタデータの仕様をどれだけ作り込むか

  • スモールスタートがよい
  • 90%は単純なメタデータで事足りる
  • 一部のスペシャルケースだけoverrideするとよい

When to Use It

• DBマッピングの労の多くを省ける

• が、弱点も

  • セットアップ処理が必要

    • メタデータ読み込んだり
  • メタデータをゴチャゴチャにする例外的なヤツもいる
• 市販のO/Rマッパーも内部でMetadata Mappingを行っていたりする

• 自前で作る場合はトレードオフを勘案せよ

  • DBマッピングコードを手書きする場合との比較

    • リフレクション方式の場合、パフォーマンスを実測する

• Metadata Mappingの前段として、Layer Supertypeで処理を共通化せよ

  • 【補】Template Method Pattern

• Metadata Mappingとリファクタリング

  • アプリケーションコードのリファクタリングの妨げになりうる

    • 自動リファクタリングツールで特に

      • コード生成

        • XML内のフィールドは拾ってくれない
        • 生成後のコードに対しては自動リファクタリングできるが、結局再生成で上書きされちゃう

      • リフレクション

        • 識別子置換漏れがあっても警告とか出ない

  • DBリファクタリングはやりやすくなる

    • Metadataがインタフェースの役割を担う

      • テーブルスキーマの変更はMetadataの変更で吸収でき、Domain Modelに跳ねない

コード例

• 略
•