# Web Applicationを綺麗に設計するためにMVACは必要ない。 _published: 2011/03/10_  MVACというアーキテクチャを解説した記事が人気っぽいです。はてな発祥なのでしょうか、解説してる記事が他には見当たりません。 - [Web Applicationを綺麗に設計するためのMVACという考え方 - Dive into the Tech World!](http://d.hatena.ne.jp/shiba_yu36/20110303/1299123350) - [補足 - Web Applicationをきれいに設計するためのMVACという考え方 - Dive into the Tech World!](http://d.hatena.ne.jp/shiba_yu36/20110308/1299539589) この記事だけを読んだとして、結論から言うと、Aは必要ありません。ここで言うAは、MVCのMに含まれます。あえてAを分離する必要性はありませんし、むしろ、分離できるものではありません。（追記）と思ったんですが、書いてるうちに、Aの役割が曖昧だから議論できないよなという結論に達しました。 先に書いておくと、id:shiba_yu36を攻撃する気は微塵もありません。勉強熱心な人は無条件で応援したくなります。ただ、はてブのコメントを見ると、この記事「だけ」で無条件にMVACを受け入れている人がいるようなので、それはどうかなと思いました。 そもそも、前提となっているControllerが汚いというのは、本来Modelに書くべき処理をControllerに書いているからです。なんだか、あの時の話と同じ感じの議論ですが。 - [[Ruby on Railsは「えせMVC」じゃないよー]] ちょっと、上記のMVAC記事のサンプルについて。まあ、補足のほうでサンプルの書き方が悪かったと書かれていますが。 ```perl # lib/Mvac/Sample/Controller/Products.pm my $app = app_class('Products')->new; ``` ```perl # lib/Mvac/Sample/App/Products.pm my $model = $self->model; ``` この2つのコードを見ると、Controllerは複数のApplicationを呼ぶことが可能であり、ApplicationとModelは1対1で対応しているように見えます。Applicationが複数のModelを呼び出すという説明と矛盾します。Perlのコードを読めないので、読み違えていたらスミマセン。 それはいいのですが、こちらが問題です。Applicationの中で行っている処理です。 ```Perl # save small image # save large image # order # save product ``` 本来Modelでやるべき処理をApplicationでやっています。これでは、ApplicationとModelの責任分担が曖昧になってしまいます。Applicationって何でしょうか。必要ないんじゃないでしょうか。 補足の記事で。 > DBへのインターフェイス、オブジェクトの層、ロジックの層など全てを含めてModelだと理解しています。 と書かれていますが、そうであれば、なおさらApplicationは必要ないはずです。と思ったら。 > Applicationの層は、実際にはビジネスロジックではありません。僕自身はビジネスロジックはModelの層だと考えています。これに関しては前回の記事の「Application層」の説明と「サンプルのApplication層の書き方」が悪かったと思っています。 ということで、大元の記事はまったく意味がない記事となってしまいました。じゃあ、Applicationって何だ？という話です。 ``` ただし、Application層の役割としてはそれだけではありません。うまく説明できないのですが、Application層は「さまざまなUI(?)とModelとを繋ぐ層」とでも言えば良いのでしょうか。 ``` 言いたいことはわかる気がします。しかし、これも結局、ビジネスロジックがModelに収まっていれば、UI層の変更がビジネスロジックに影響することはありません。逆に、中途半端にビジネスロジックを含んだApplicationでUI層の変更を吸収しようとすると、UIロジックとビジネスロジックが混ざってしまいます。あ。ここまで書いて気付いたんですが、UI層の影響を受けるところをApplicationにしというということなんでしょうか？ ``` この一年間勉強してきて感じたことですが、そのようなもの全てをModelとしてまとめてしまうと、初心者にとってどのように設計したらよいかわからなくなってしまいます。 ``` ``` なので、MVCをちゃんと理解できている人であれば、別にMVACとかそういうふうに考えなくても良いと思います。 ``` なるほど。前提が完全に覆るわけですね。 で、ここで、はてなのプレゼン資料を見てみます。 - [デブサミ2009 はてなの開発戦略](http://www.slideshare.net/hotchpotch/deb2009-1023281) 納得しました。アプリケーション層はページャの作成やキャッシュ操作などを担当するようです。であれば、補足記事の「Applicationはビジネスロジックではない」という通りです。それをビジネスロジックを含むかのような解説をしてあったので、誤解が生まれたのだと思います。 じゃあ、結局のところApplicationは必要なのか。何気に、ページングって、UIコンポーネントの役割なんですよね。キャッシュはユーザーインターフェイスにもサービスインターフェイスにもデーターアクセスコンポーネントにも必要で、そのうちサービスインターフェイスをApplicationと呼んでしまうんでしょうか。と考えると、Webアプリケーションにおいては、Controllerとの境界が曖昧になりませんか。 Applicationが何なのかはっきりしないので、まとまりませんね。むしろ、役割が明瞭でないものをアーキテクチャに含めるって、無理がありませんか。とりあえず、元記事であがったMVCの問題点に関して言えば、Modelに書くべきことはModelに書け、ということになると思います。 また、元記事で紹介されていた記事ですが、いろいろと勘違いされている気がします。参考にする場合は、注意してください。 - [内部WebAPIの呼び出しコスト - MVCモデルの”次” - 出町ミスド攻防記](http://d.hatena.ne.jp/kazuk_i/20090214/1234625451) あと、インターフェイスが増えると、テストが増えますね。テストしやすいというメリットを取るのはいいのですが、テストが増えるというデメリットとのトレードオフを考慮する必要があると思います。 はてブで火がつくと、補足記事書いても読まれないので、損しますね。そして、スシが食べたい。