ORM
Object-relational mapping
オブジェクト関係マッピング
上手く言語化できないが、「SQLの代替手段としてのORM」という戦略自体がズレている気がする
だからORMいる、いらん論争が起きる
なんだろう、例えば型付きSQL文を使うとか
個人的には、EntityとMappingしている部分が「ほんまにええんか？」という気持ちにもなる
Entityとtable構造が密結合している感じがするが、本当に良いのか
「SQL書くとDBのことを知りすぎ」という意見もわからんではないが、それはレイヤー作れば問題ないと思うし
ORMなら確かにDBが変わっても修正不要なのか
途中でDB変えることなんて殆どないと思うけど
「筋の良いORM」にちゃんと触れたことがないので、そういうのに触れると考え方が変わるかもしれない
そもそもここがめんどいので、そこを自動化するORMは嬉しい、となる
統一をやめる
SQLかORMかの二元論をまずやめる
全体として効率が上がれば良し
ORMを9割ぐらい使って、無理なところだけSQL書く
即ち、良いORM Libraryは、「無理なところだけSQL書く」ときも楽に書けるようにしたい
その余地を残しておく、というかなんというか
というか、queryはSQLで書いてmappingだけ自動化するのが一番良いんじゃないのか..mrsekut.icon
取捨選択するにしても、
1つのSQLを組み立てるときに
methodで書いたSQLの部分と、
nativeで書いたSQLの部分
を合成して使えないと意味ない
そうじゃないと、「今までの仕様ではこの部分はmethodで書いていた」が、
仕様変更に無理になった場合に、そのSQLをすべてnativeに書き直す必要がある
それなら最初からnativeで書いとけば良いじゃん、になる
プロダクト全体で取捨選択できる、というのは当たり前なので。
今のとこ、めちゃくちゃORMにヘイトが溜まっているが、
Doctrineしか使ったことがないので、
一般的なORMがそもそもクソなのか、Doctrineがクソなだけなのかは判別がついていないmrsekut.icon
Prismaも触ったことあるけど、軽くしか触ったこと無いので評価できない
軽く触った感じは良かった
複雑なことしようとするとキレるかもしれない
ORMには抽象度の5つのレベルがある
高い抽象度のものはより簡潔にかけるが柔軟性が低い
そういったレベル感を知った上で目的とマッチしているかを見て採用する必要がある
この記事はJavaを使っていて各レベルに相当する実際のORMで話をすすめる
レベル 1: 低レベル API
queryはSQLで文字列で書く
結果は手動でsetterを使ってinstanceを作っていく
リソース管理や例外処理も必要
これってORMって呼ぶの？ってぐらい特に何もやっていない
レベル 2: 前後処理の抽象化
queryはSQLで文字列で書く
結果は手動でsetterを使ってinstanceを作っていく
レベル 3: クエリと単純なオブジェクトのマッピング
queryはSQLで文字列で書く
mappingはやってくれる
がtable結合した際の他のobjectを取ってこれないらしい
つまり、単体のEntityしか取得できない
レベル 4: クエリと関連ナビゲーション可能なオブジェクトのマッピング
queryはSQLで文字列で書く
XMLやらで結合込みのmappingの指定をする
結合込みのmappingのためにannotationとかが必要になるのかmrsekut.icon
レベル 5: テーブルとオブジェクトのマッピング
Entityにannotationでmappingの指定などをする
パフォーマンスの問題になりがち
mappingがだるいのはOOPのせいだと思うので、class指向を辞めればマシになそうな気はするmrsekut.icon
こわーいmrsekut.icon*2
アンチORM