最近のアプリやシステムサービスはおおよそMVCモデルで作られることが多い。モデル-ビュー-コントローラ

データ(DB含む)はモデルとして定義して、概ねクラスで作る。

コントローラは呼び出し元(httpサーバー経由で来るユーザ操作とか、デバイスからの呼び出しとか、外部サーバーからのAPI呼び出しとか)からの要求を受け付けて、モデルに突っ込んで、サービスを呼んで加工し、ビューで返すべき結果にまとめ直して、呼び出し元に返す。

こういう形式にまとめられた理由について、論理的な解説書はいろいろ理由を書いているがその個々は私は別に頭に入ってはいない。読めばもっともだと思う。

でもプログラムはそれにはまらない書き方は出来るし、クラス分けも別の見方の分け方もできる。初期のオブジェクト指向系の人(教育系のSmalltalkの人とか)にすれば現実モデルと全然合致しないと言うかもしれない。

なんでDBのレコードって現実世界に実物が存在する物ではないのにクラスになるのかとか、レコードの分割単位は実際のオブジェクトの単位ではなかろうとか。オブジェクトのほうにモデルとスキーマをがっちり合わせたらRDBの形には入らなくなる(もちろんそっちの考え方のシステム/言語も今はいろいろあるだろう)。

でも、なぜこの分け方が多いかは単純に「たくさんこの手のシステムを作った人から見て、こう分けたほうが後々を含めて一番手間がかからなかった」という経験知見ということだろう。

建物を建てるときに、1階より2階を大きくした建物を作ることは出来る。芸術家がデザイン的に建てる場合もあるし、立地上そうする必要があったということもあるだろう。でも特に条件が無ければ2階は1階と同じか小さくしたほうが建てやすい。

プログラムの規模が小さいうちはどうとでもなるのだ。段ボールの家なら1階と2階がどういう関係でも問題ない。実用的な規模、または大規模なシステム、多人数、多数の企業が関わるシステムだと、大枠が合理的にわかりやすくないと破綻する。経験・知見でこれいいよね というアプリ/サービスの作りの一つがMVCである。

経験知見により取捨されていく方法論は大事にすべきなのだろう。ただ将来ともその知見通りとは限らない(とにかくソフト分野はカルチャーが常に変わり続ける)。自分の若い頃の知見(コンピュータの都合に合わせたシステムが後々手間がかからない)は、技術と方法論の進歩でいくらでも変わっていくのだ。