【移行記事】O/Rマッパーの採用・不採用で意見が割れている

※この記事ははてなブログからの移行記事です。

12:58:12

リードエンジニアの方と別のメンバーの間で O/R マッパーを採用するか否かで意見が割れている。正確にいうと、議論しているわけではなく各々のやり方で進めちゃってる感じ。

別のメンバーの方が採用している O/R マッパーは、ツールを導入しておらず独自にそれ専用のクラスを作ってる。簡易的にプログラム構造を書くとこんな感じ。(果たしてこれを「O/R マッパー」と呼んでいいのかな?)

View - Controller - Model - テーブルデータ格納用クラス - Service - DB

僕としては O/R マッパー不採用が良いと考えている。

まず、(良いかどうかは別として)オブジェクト指向プログラミングをゴリゴリ使っていく、という方針ではないので「データベースをオブジェクトとして扱える」という O/R マッパーのメリットにほとんど意味がない。むしろ O/R マッパーが間に入るだけ無駄なコーディング量増えてしまう。

また「SQL を書かなくていい」というメリットさえ無い(どうせ SQL を自分でサービス層のクラスに書かないといけない)

DB アクセス部分を Service にまとめられるという意味では役立つとも思ったけど、Model と Service を分けるほどのボリュームが無いので、いまのところは分ける意味もあまり無いと思う。

まあ O/R マッパーを使うなら使うでもいいけど・・・せめて方針は統一して欲しい・・・。

あと、大変ヤヴァイことに今のプロジェクト、コードレビューもしなければテストコードも書かない方針になってる。他のメンバーが書いた機能を壊しているか確認する手段が無いので、共通クラスや再利用を前提としたクラスは危なっかしくて使えない 😇