※ 私のエントリだけだと偏り過ぎているので、是非このエントリへの@wtnabe@githubさんのフォローも含めてご覧下さい。素晴らしいフォローに多謝。
http://qiita.com/joker1007/items/2a03500017766bdb0234
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
この二本読んでいて、昔なら前者を「わかってないなぁ」とか思う所なのだけれど、ひょっとしてひょっとすると自分が設計のレベルでも完全なオールドタイプになってしまったのでは無いかと不安になったんだ。
そもそも、自分はコントローラーがモデルを直接弄る設計をせずに、所謂サービスの層を作成していたんだ。だけれども、時代とともにフレームワークが多くの機能を持つようになってきて、Controllerとサービスの差、サービスとModelの差が凄い勢いで狭まってきている気がする。昔はサービスにはロジックがガッツリ乗ってくる。当時ならDAOを操作してデータを構築するロジックだの、外部システムへの働きかけだの、とにかくごちゃごちゃしそうなものは全部この中に押し込めた。WEB層とロジック層の境界線がサービスの表面だった（はず）。ロジックのテストはこのサービスの層を叩いた。DAOも分離して、DBに繋がなくてもテストが出来るような世界を構築したりするのが普通だった。
だって、DBって内部ネットの共有オラクルとかだもん。自分のPCになんて入れないもん。fixturesなんか使ったらみんなが同時にテストできないもん。
WEB含んだ総合的な自動テストをするよりも、ロジックだけのポータブルなテストが重要視されていた。アウトプットはJSONではなくHTMLだったため、URLを叩けばデータが返ってくるという時代ではなかった事も理由だろう。そして「その為の設計」をしていた。
最近RoR4であるサービスのプロトタイプを作成した時にラピッドにサービスを作らない縛りでやっていたら、以前だったらサービスの層でやっていたはずのコードが、モデルへのプロパティ一発で出来ていたりする事に助けられた。
例えば、親子関係を持ったPOSTデータを受信する際に「とりあえずコントローラーが汚れてもいいや」と一瞬コードを書き始めるのだけど「ひょっとして？」と思って調べてみたら、
accepts_nested_attributes_for
なんてものがあるんだとわかった。これ、モデルのプロパティ一つで上記の複雑なデータ構造を保存できてしまう。あれ？それなりに書くだろうと思っていた所が一行で終わった…。
そんな話を一昨日、僕の事を師匠（嬉しい）とかオカン（嬉しくない）とか呼んでくれる若いイケテル技術者（あるとこのCTOだよ！若いのにすげぇよこいつ）と話していたんだけど、サービスなんて作らない。シンプルなMVCが一番わかりやすいでしょってことだった。
時代は変わった。DBはMacBookAirの中に一緒にインストールされて、フレームワークのサポートが遥かに増した。作られるWEBサービスの規模自体も小さくなった。JSONのin-outでテストできる。だから以前当然必要としていた考え方は不要になってしまったのだろうと感じた。
それはちょうど僕が若い頃「どうしてインターフェース使ってポリモーフィズムしないの？何無駄にifで分けて関数ダラダラ量産するの？あのC上がりのロートル達は」って（口には出さずとも）思っていた事が、僕に襲いかかってきたのだ。それはとても恐ろしくて悲しい事だ。
さて、それを知った僕はもう少し頭の中を切り替えてみたいと思っている。今の人達の大勢が許容するような設計や、フレームワークの作り方を考える必要があるかもしれない。そうしないと、僕が基礎を作ったシステムは今の若い人達にとって単純に使いづらく、醜いゴテゴテしたものになるから。
そうやって自分の知識が古いものになったと改めて実感する。それでいいじゃないか。と老いた自分を慰めた。