BEAR.Sunday以前のフレームワーク、BEAR.Saturdayがページとリソースというレイヤーを持っていました。
https://blog.excite.co.jp/exdev/25879834/
MVCでいうとコントローラーの役割が"ページ"。ページクラスはコントローラーと違ってルーターによるメソッドのマッピングは必要なく、HTTPメソッドにマップするメソッドがありました。
モデルの役割が"リソース"、メソッドはCRUDに対応した名前を持っていました。
コントローラーやモデルのメソッドに制約を加えセマンティックスを与えていました。
-
BEAR.Sundayでは、CRUDではなくRESTのメソッドにマップしました。
-
ページとリソースを構造だけでなく実装も全く同じにし、PageリソースとAppリソース、どちらも同じにしました。
BEAR.Satuday、BEAR.Sunday双方で、MVCの構造をマップしてメンタルモデルを構築しやすいようにと言う意図がありました。
ユーザー(HTTP/CLI)のUIはPageリソースが担います。ユーザーはその先についての関心がありません。リソースが解決するドメインの問題はサブドメインに分けられ、それぞれAppリソースが担います。
例えばPageリソースに「送金」のリクエストがあったときには、Pageリソースが、アカウントリソースなどのAppリソースを操作し、Appリソースはまた別のAppリソースを操作したり、含んだりして解決します。
-
Pageはユーザー(HTTP)とのUI、ドメインの問題解決
-
Appリソースはサブドメインの問題解決、ドメインストレージへのアクセス
AppリソースはPageリソースは呼ばれる関係です。逆はありません。
チュートリアルではPageリソースでHTML、AppリソースでAPIレスポンスを生成しています。 このとき、ユーザーにPageリソースは公開されていますが、Appリソースは公開されていません。
(組織内やテスト時など)コンテキストを変えHTMLアプリケーションから、APIアプリケーションに構成を変更し、Appリソースを公開することができます。
この2つを分ける必要がないのではないか?と言う議論は最初からありました。例えば可視性をPage/Appのスキーマでなく、パスで分け公開しないリソースを/api/
にしてそこに対して非公開のインターセプトをすればいいなどです。
1つではいいのかという考えに対して、Page/App以外のリソースが必要かもしれません。(例えばhttpで始めるhttpリソース)ユーザーが独自にスキーマを設定できる仕組みを用意しました。
アプリケーションのリソースの構造をどうするのか、結局のところ最適な意思決定ができるのは、フレームワークアーキテクト(フレームワーク作者)ではなく、アプリケーション・アーキテクト(ユーザー)です。
可視性や有効なMVCのメンタルモデルなどを考え2層のリソース構造を提示しながら、それをアプリケーション・アーキテクトが変える事を邪魔していません。