MVCにはあまりにも多くの派生パターンがあるので、「あなたが言っているMVCは私のMVCと違うね」みたいなことが頻発する。いっその事、MVCは NGワードにしたほうがいいんじゃなかろうか、とは俺も思う。

matarillo: UIパターン

現在のSmalltalkの世界では、すでに Model – View – Controller というナイーブなアーキテクチャは使われておらず、 Domain Model – Application Model – View – Controller という PluggableMVC (or MMVC) と呼ばれるアーキテクチャに移行している。

結城浩氏 – MVCとはModel-View-Controllerの頭文字をとったものです。

MVCフレームワーク?

リクエストを受け取ったフロントコントローラ内がURIを解析し、ルータやディスパッチャでモデルやビューが呼ばれるものをごく一般的なWeb MVCアプリケーションフレームワークだとすると、BEARは数々の相違点があります。

MVCは責務という関心の分離1ですが、そこだけに注目すればBEARのPage-Resource-ViewはMVCのバリエーションの一つかもしれません。ですがコンポーネントの働きとやり取りに大きな違いがあります。最大の相違はモデルの部分です。BEARのモデル（Resource）はオブジェクト設計を前提にされたものではありません。またフロントコントローラーを持たず、ブラウザから入力されたURIが特定のコントローラーやモデルを指す事もありません。URIを規定するのはフレームワークではなくアプリケーションです。

リソース指向アーキテクチャ

コントローラーとモデルの関係や、モデルのあり方にROA2（Resource Oriented Architecture）を持ち込んだのがBEARの基本コンセプトです。モデルはリソースとして扱われ、ページコントローラーからのリソースリクエストは決まった一つの方法しかなく、返ってくるデータもリソースオブジェクトというコード、ヘッダー、ボディを持つただ一つの型でしかありません。ここでリソースはデータであり、APIでもあります。

リソースレイヤー

（BEAR内部の）リソースURIの向こう側に高度にモデリングされた複雑なドメインモデルがあるのか、news.csvファイルが置いてあるだけのかはページ（コントローラー）は感知しません。URIの違いがあるだけです。URLを入力して表示されたHTMLページが高度に洗練されたクラウドで動いてる超システムの結果なのか、ホームページビルダーで作成したHTMLファイルなのかはwebブラウザは感知しないようなものです。そういう意味でBEARでのリソースはレイヤーとして振るまいます。ページからリソースへのアクセスはアプリケーションレイヤーからリソースレイヤーへのアクセスといえ、ビジネスロジックとしてのモデルとは言えません。ここでリソースはサービスレイヤーです。

today/newsリソースとtoday/wheatherリソースを利用するtoday ページ（コントローラー）は、その２つ（today/news、today/wheather)リソースをもつtoday pageリソースとしても扱えます。MVCであてはめると２つのMを扱うCが、一つのMになることができるということです。そのページリソース(page://)というMは別のページからも使えるし、ページをテストするテストコントローラからもアクセスできます。ROAのレイヤリングの原則が適用されます。

Because Everything is A Resource.

オブジェクト指向においてオブジェクトが主役であるように、リソース指向においてリソースが主役です。リソースの制御ですらリソースそのものになるリソース指向がBEARであり、ROAの世界です。何故かというと全てはリソース 3だからです。

参考リンク

  1. 関心の分離 – Wikipedia [↩]
  2. リソース指向アーキテクチャ（ROA）- 岩本隆史 [↩]
  3. Because everything is a resource. [↩]