実は、今は新会社のシステムを作るために、新しいフレームワークを作ろうとしている。基本はMONTSUQIなのだが、もっと柔軟にしようという考えだ。

MONTSUQIは典型的なMVCに基いた設計になっている。MVCは完全に分離され、VにMやCが引っぱられることはない。つーか、Vはweb だけではなく、いろいろなインターフェイスが用意されているので、MやCがVに引っぱられるとVの汎用性が下がる。まぁ行儀の悪いプログラムが書けないわけじゃないので、Vに依存したMやCも書けないではないが。

MONTSUQIには外部インターフェイスが2つある。それはMONTSUQI配下のデータベースをアクセスするためのインターフェイスと、 MONTSUQI配下のアプリケーションをアクセスするためのインターフェイスだ。そして、これらは実はほとんど同じである。つまり、Mの外部インターフェイスとCの外部インターフェイスは同じなのだ。

使い方を考えても、たとえば「ある診療行為の保険点数を求める」というのは、Mをアクセスして自分で頑張って計算する方法と、Cをアクセスしてお任せで計算する方法とが作れる。Mをアクセスする時には、「ちまちまとデータベースから値を取り…」の繰り返しで、Cをアクセスする時には「とっても偉いデータベースが何でも教えてくれる」と見える。

まぁこれはMONTSUQIの例であるが、今時のwebサービスやらを見ると、「本来Vが載る部分をMとしてアクセスする」というものが少なくない。つか、全部それだと言っても過言じゃない。

という現状を見ると、Vは別にして、MやらCというのは相対的なものでしかない。元々OOPなんてのはそういった「相対的な階層」の中にあるものだから、物事は「自分から見た相手」という相対的な位置関係が基本だ。

そう考えると、OOなものが当たり前になったり、OO的によそさまのシステムをアクセスしたりするということが当たり前になったりすると、「何が Mで何がCか」ということは、相対的なものになってしまう。こう言ってしまうと、「そんなの当たり前じゃん」と言うかも知れないけど、Javaだろうが PHPだろうがRubyだろうがCOBOLだろうが、「UIのあるものはMVCモデルで」という「常識」と矛盾する。矛盾すると言うか、やりにくい。むしろ、「固定的なMVC」なんてのは「OOの邪魔」にさえ見えて来る。OOな世界では、「MVCは相対的なもの」だと思った方が良いのではないか。

とか思ってるけど、私は何か勘違いしてるかな？