Rails雑感 - 愛と勇気と缶ビール

最近、いわゆるRailsの古めのバージョンで書かれたプチレガシーな感じのアプリケーションを触っていて思ったこと。

ちなみに、この話題は多くの人にとって大分今更感のある内容なので、逆にこれを読んで「今更だなぁ、そんなのとっくに結論出てるでしょ」と思わない人はヤバい。

めんどくさいのでデータ永続化を行うためのミドルウェアはMySQLという前提で書く。

単純に言うと、いわゆるRailsアプリのMVCではMがActiveRecordかなんかを継承していて、そのまま作るとModelとtableが一対一対応になってしまう
- これだと、どのModelにも属さないようなビジネスロジックを置くべき場所がどこなのかよくわからない
- 「どのModelにも属さないようなビジネスロジックなんてないでしょ！」「どのModelにも属さないビジネスロジックがある時点で設計おかしいでしょ！」と思った人は幸福である。頭が。
ちなみにビジネスロジックどこに置くべきか議論は、Perlコミュニティ的には2008年とかのCatalystうんたらかんたらの時点で割と結論が出ている
- 要はデータソースとしてのModelの前にLogic（正直これに付ける名前は何でもいい）みたいのを立てて、ここから複数のModelを操作してビジネスロジックを記述すればええやん、という話
某先輩の言う所では、「そもそもMySQLのtableみたいな、裏のミドルウェアのデータ構造にベッタリ対応したモデリングをするのは筋が悪いことは大分前から分かりきっている」。確かに。
また別の某先輩の言う所では、「90%の場合はActiveRecordの諸々の機能を駆使すれば上手くいくので、残り10%をフォローするために（フレームワークとして）さらに一つレイヤを分ける必要はないと思う」
- フレームワークレベルで分ける必要までは確かにない気もする
- が、実用的には、よっぽどスモールでおもちゃみたいなWebアプリケーションでもない限りビジネスロジックを置くレイヤを別途設けた方がスマートな設計になると思う。初めは単純なCRUDだけに見えても、ビジネスロジックは時間が経つにつれて肥大する
ちなみにMVCかMVPかMVVMかPMかMVLCか、みたいな話がしたいわけではない
- 名前とか定義とか元々はSmalltalkがどうとか、そんな議論はどうでもいい、まともで健やかな開発を行うためにはどういう設計がいいか、それだけの話だ

この辺の問題意識って実際どうなってるのかなあ、と思いつつRails AntiPatterns: Best Practice Ruby on Rails Refactoring (Addison-Wesley Professional Ruby Series)とかいう本を読んでいると、途中までは「scopeとかassociationとか駆使すればええやん」というノリだったのだが、なんとなくそれっぽいライブラリに行き当たった。

https://github.com/jamesgolick/active_presenter

あまり使われているような雰囲気を感じないが、どうやら問題意識のある人はいるらしい、ということがわかった。

総合すると、「Railsではこう書くんだよ」みたいなお作法があろうがなかろうが、必要に応じてその辺はスルーして自分の思うあるべきクラス設計をすればいいんじゃなかろうか、というのが今の結論。
（もちろん、チームとして開発するんだったらちゃんとした合意があった上で、の話ですけどね）
Webアプリケーションフレームワークなんて所詮フレームワークに過ぎないんだから、それに振り回されるのは不毛である。