補足 - Web Applicationをきれいに設計するためのMVACという考え方

　Web Applicationを綺麗に設計するためのMVACという考え方 - Dive into the Tech World! では、様々な意見をいただきありがとうございました。コメントを見る限り、うまく伝えきれていないなという部分がいくつかあったため、補足としてまとめたいと思います。

前提

　前回の記事は一応前提として、以下のようなものがあります。

Web Application設計の新しい手法を提案したわけではない
- 昔からある手法の理解が自分の中で深まったので、まとめてみたわけです

もらった意見とその補足

MVCにおけるMの定義がおかしいのでは

Mの定義がおかしいから、Aがある
データモデルがMと思うと失敗する

　これに関しては、「MにSkinnyを」などというように、記事の書き方が少し良くなかったのではないかなと思いました。Mに関しては、DBへのインターフェイス、オブジェクトの層、ロジックの層など全てを含めてModelだと理解しています。今回はApplication以外はSkinnyでしか書いていなかったので、そのような記述をしてしましました。

全く真新しくない

　これに関しては前提で述べたとおり、新しい手法を提案したわけではありません。僕自身が実際にプログラミングをし始めたのは一年前で、それ以後自分が実際に経験したMVACというアーキテクチャについて、ようやく理解が深まってきたので、まとめてみたということでした。
　MVPとか、他にもいろいろな手法があるみたいですが、これに関しては知識がありませんでした。

Aは結局ビジネスロジックのことなのでは？

　Applicationの層は、実際にはビジネスロジックではありません*1。僕自身はビジネスロジックはModelの層だと考えています。これに関しては前回の記事の「Application層」の説明と「サンプルのApplication層の書き方」が悪かったと思っています。

　まずApplication層があることで、Controllerが綺麗になり、テスタビリティが向上するというメリットがあります。ただし、Application層の役割としてはそれだけではありません。うまく説明できないのですが、Application層は「さまざまなUI(?)とModelとを繋ぐ層」とでも言えば良いのでしょうか。

　文章だとうまく説明できないので、下の図を見てください。

　このようにWeb ViewだけでなくCUIやGUIでのインターフェイスなどからも利用出来る層をApplication層として考えています。そのため僕は、Web Viewの場合はControllerにApplicationを一対一対応させ、そのControllerでのみ使うメソッドをApplication内に定義しています。もしCUIで使うときには、コマンドとApplicationが一対一対応を、GUIの場合は画面セットとApplicationが一対一対応になるのだと思います。
　僕は今までWeb View以外にはUIをつくってこなかったため、「さまざまなUIとModelを繋ぐ」というメリットをうけたことがありませんでした。そのため、前回はこの説明が抜けてしまいました。もちろん、Web View以外のUIを作らない場合でも、この役割を意識して作成することでController内にロジックを書いてしまうことを防ぐことができるので、前回書いたようにテスタビリティの向上などを望めます。

　また、サンプルに関しては特に大きなものでもなかったので、Application層とビジネスロジック層を分離せず、書いていたというだけです。

　以上、いまいちうまく説明できませんが、Application層の説明でした。

それって結局MVC

　結局MVCだよねという意見をかなり多くいただきました。もちろん従来のMVCにおけるMの定義はかなり範囲が広いので、Application層もModelに分類されると思います。ただ、この一年間勉強してきて感じたことですが、そのようなもの全てをModelとしてまとめてしまうと、初心者にとってどのように設計したらよいかわからなくなってしまいます。

　そのため、「ControllerとModelを繋ぐ役割」を新しくApplication層と名前をつけることで、さらに役割を明確にするため、MVACと言われていたのではないかと思います。

　なので、MVCをちゃんと理解できている人であれば、別にMVACとかそういうふうに考えなくても良いと思います。

最後に

　前回と今回の二つの記事で、ようやく理解できてきたMVACという考え方についてまとめてみました。

　MVACについて、いろいろと説明してきましたが、実際に全てに適用しなければいけないのかと言われるとそうではないと思います。
　非常に小さいアプリならば、そもそもControllerにロジックをべた書きしたほうが、速く出来る場合もありますし、ある程度の大きさなら今回のサンプルのようにロジックの層とApplicationの層を同一視しても良いと思います。そもそも、全く別のアーキテクチャを使ってもいいと思います。
　結局はその時やりたいことに合わせて、適切な設計を考えればよく、その中の一つとしてMVACというやり方がありますよということです。

　また、コメントやブクマなどで、様々な指摘をしていただいてありがとうございました。MVPや、構造のパターンとインタラクションのパターンの違いなど、僕にとってまだ知らなかった知識を知るきっかけになりました。今回指摘してもらった内容からさらに勉強したいと思っています。