BitArts Blog

ロードバイク通勤のRubyプログラマで伊豆ダイバー。の個人的なブログ。

エセMVCプログラマですが

僕はMVCの歴史的経緯などを知らないエセMVCプログラマですが、そもそもMVCが役割分担化を目的としたものだと考えると、1つの層だけが極端にファットになるのは良くない感じがしますよね。

各オブジェクトの役割を定義して、どのオブジェクトに何を実装するかというのはOOPにおいて基本であり最も重要なことですが、最も難しい部分でもあります。「なんでもかんでもここに書けばいい」というのはもはやOOPではありません。優れたフレームワークを使ってもプログラムの設計をするのは結局プログラマです。オブジェクト指向の理解がなければうまく組み立てることは難しいでしょう。

今のところ僕の場合は、Webに依存しない業務ロジックはModelに実装(AR以外の非永続Modelを含む)。Webアプリだけで必要なロジックで特定のアクションでしか使わないものはControllerに実装。ページごとのユーザーインタフェースはViewに実装。な感じでやってます。

某所で書かれていたこととは僕には印象が逆で、Railsの場合はModelとなるクラスにアクセサなどの実装が現れないので、Modelにロジックを書きやすいフレームワークだと感じています。

Viewについては一番難しいところです。僕は長らくViewは薄くあるべきだと信じていました。特にテンプレートはデザイナーが納品したHTMLファイルそのまま。みたいな(具体的実装としてはAmritaとかTapestryとかMayaaとか)。なのでRailsがERBを採用していることが個人的にはいやだったのです。

昔作ってみた、こんなの↓

でも最近はViewにもそこそこの量のロジックが入ってしまうのは避けられない感じです(と言ってもERBに全部書けというわけではなくHelperとか使うべきですが)。「見た目」だけでなくUIも含めてViewだと考えれば、UIを組み立てるためのロジックが当然入ります。最近はWebアプリのUIがHTMLベースでも非常に複雑化してきています。JavaScriptも含めて考えれば結構な量のロジックが入ってしまうことは結局避けられないし、避けてしまうと複雑なUIを作りづらくなってしまう。なので今のRailsのViewは好きではないけど実は意外と実用的には使いやすい気もしてきています。

まあ、話が脱線しましたが。

Ruby on Railsは素晴らしいと思いますが、もう少し具体的な実装例があるといいよね。っていうか、あるんだろうけど、Railsでの推奨実装があまり知られていないからあんなことを言う人がいるのではないかと。

コメント

2009/10/14 20:28 from Q

 あのネタは各所でトラックバックされていますね。私はOOPの経験が殆ど皆無なので詳細は理解できないのですが面白い。みやまえさんのこのエントリも興味深く読ませていただきました。