雑感
- インピーダンスミスマッチを解消するためのアプローチをひっくるめてORMというらしい。つまり、インピーダンスミスマッチがキーワード。
- とりあえずDDDとか出てくるけどそっちには(本質的には)関係なさげ
- ORMよりO/Rマッピングでググったほうが解説が易しい気がする
インピーダンスミスマッチについて
- オブジェクト指向でいうところのオブジェクトとDBとのデータの範囲(オブジェクトとかテーブル)の違いのこと
- あるオブジェクトの情報を取得しようとしたときに複数のテーブルからデータを集めるとかそういうこと
- 継承が発生した場合に継承先のオブジェクトで必要なカラムが継承元用のORMオブジェクトで定義できない
- 解決法としては静的動的いろいろあるけど、その部分を吸収してくれるのがORMオブジェクト
ORMの向き不向き
- 向き不向きがあるらしい。全カラム(SELECT *)できるようなテーブル設計だといいのかもしれない
- テーブル設計をオブジェクトに合わせて柔軟に変更できないとORMが足かせになるという記事も・・・
- また、フレームワーク/ライブラリ毎にアプローチも結構違うらしいので、思っている以上に範囲の広い言葉
- 完全にORMオブジェクトのみで開発するのは無理があるという意見が多数の模様
ORMの利点
- テーブルの(疑似)差分継承ができる！
- ↑と書くと誤解が生まれるかもしれないが、継承元のORMオブジェクトが管理しているテーブルと継承先のORMオブジェクトが管理しているテーブルが合成されたテーブルを扱うことができる模様
- ↑これによりOOP時のオブジェクトのデータと整合性を取ることができるのが最大の利点
ORMの欠点
- 全部SELECTするorクエリの数だけORMオブジェクトを定義する
- 全SELECTは兎も角、クエリの数だけ定義の対処方だとオブジェクトの管理で死にそう
- それでもカバーできない部分はSQLを直書きする必要がある。これによりソースの統一性が損なわれる
個人的結論
- ORMを使うかどうかはどちらを推すにせよ宗教
- ORMを使うのであればModel層をORM用とそれを使うModel用に切り分けるのがわかりやすそうに感じた(未使用者の感想です
FuelPHPだと
- リレーションの設定などをORMのModelクラスに内包？
- FuelPHPのORM
- FuelPHP Orm
- FuelPHP1.6、ORMモデルのfind()を理解する。
参考サイト
O/Rマッピングで緩和されるインピーダンスミスマッチには静的と動的の側面がある
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？
O/Rマッピングツールに対する誤解をときたい
ORM利用すると性能が出ないってホント？
インピーダンス・ミスマッチを解決する、O/Rマッピングの設計
ORMがアンチパターンである11の理由