【PHP】PDOを利用したDB操作をクラス化する時は『テーブル単位』？『DB単位』？

前書き

　Webシステムを構築する際、Rubyを使おうがPHPを使おうが、ほぼ間違いなくMVCデザインパターンを意識しなければならない。それに伴い、DB操作をクラス化する必要性が出てくる。
(でないと、モデルを介さずに、コントローラが直接データを整形し、ビューへ送る仕組みになってしまい、MVCデザインパターンが実現できないため)
　で、実装～テストが終わった段階で、ふと思ったのが本記事のタイトル。

クラスの作成単位は『テーブル単位』？『DB単位』？

Railsはテーブルを作った時(db:migrateした時)に自動でクラスが付いてくる＆メソッド定義済みなのでそこまで考えなかったが、PDOを利用した際のDB操作手順(後述)を考えると、「DB単位でクラスを作成するのもアリなのでは？」と思い始めた。

考察

　PDOを利用した方ならお分かりかと思うが、PDOオブジェクトはDB単位で作成される。
RubyOnRails等ではテーブル単位でモデルに対応するクラスが作成されるので若干不自然さはあるものの、PDOオブジェクトの性質上、DB単位でまとめてクラスを作成するという方法もありなのでは？

• メリット

  1. PDOオブジェクトの定義単位と一致している
  2. クラス名を気にすることなく、テーブル間の結合を行うことが出来る。
     • PDOからDB操作を行う場合、「DB単位で操作用オブジェクト定義→SQLを作成→実行」という3ステップであり、どこにも「テーブル単位の制約」が存在しない。

• デメリット

  • クラス自体が肥大化してしまう
    • テーブル単位で分けていてもそこそこの行数になるクラスが、扱うテーブル数に合わせて単調増加する。(僕の携わったものでさえ、テーブル2つに対してそれぞれ200行弱)
    • 保守性の損失が大きい

先輩の意見

　同じ案件の先輩に本議題をぶつけたところ、『テーブル単位派』という意見でした。
理由として、「クラスが肥大化する。」「PDOオブジェクトはあくまで『操作用オブジェクト(ただのコントローラ)』であり、クラス作成単位に影響を及ぼさない。」「仮にDB単位で一つにまとめているのを見かけたら、もうサボってるようにしか見えない」等など。。。確かにそうですよね。
　一方で、メリットの2つ目については「実装の度にどうすればいいか考えている部分」「もうある程度のクラス名称と扱うテーブルとの齟齬は仕方ないのでは？」とのこと。

意見を踏まえた上での考察

　先輩の意見の中にもあった、「PDOオブジェクトはあくまで『操作用オブジェクト(ただのコントローラ)』」は盲点だったなと。PDOオブジェクトの単位にあわせる必要はないのであれば、DB単位でクラスをまとめる必要もなく、テーブル単位でクラスを分ければよい。
　結論、他の実装方法と同じ『テーブル単位でクラスを作成するほうが良い』という流れになったため、ほぼ無意味な議題となったが、「テーブル操作用クラスの中でInnerJoinする際の不自然さをどうするか？」という部分に触れられただけ有意義だったかなと。