ＭＳ（ＥＸＣＥＬ，ＡＣＣＥＳＳ）のアプリケーションを作っていて、
ＭＶＣというものに当てはめるとどうなるのかを考えてみた。
１）ＡＣＣＥＳＳ
アクセスはデータベースアプリケーションである。
アプリケーションの中には、テーブル、クエリ、フォーム、レポート、マクロがある。
ＶＩＥＷ） フォーム、レポート → これは確実にビューでしょう。
ＭＯＤＥＬ） テーブル → データベースの中身なのでテーブルはモデルだろう。
ＳＱＬを処理しているＡＣＣＥＳＳ本体もモデルということになる。
ＣＯＮＴＲＯＬ） フォーム、クエリなどもコントロールだろう。
マクロ、イベントプロージャは、用途によってはコントローラということになるかな・・・
２）ＥＸＣＥＬ
エクセルはどうだろうか？
エクセルの役目は、グラフを書いたり、シートにデータを入れたり、ピボットを計算したりすることになる。
これはちょっと難解だ・・・
ＶＩＥＷ） グラフ
ＭＯＤＥＬ） シート、シート関数
ＣＯＮＴＲＯＬ） ＶＢＡ
さて、ここまで書いたのには、それなりに理由がある。
ＡＣＣＥＳＳもＥＸＣＥＬも、半ば完成しているアプリケーションなので、
これはプログラミングからの観点からは、一種のフレームワークと見なせるのだ。
であれば、ＶＢＡのプログラミングでは、ＡＣＣＥＳＳ，ＥＸＣＥＬの良いところだけ使って、
あとは、プログラミングで補ったらどうかなと思うのである。
つまり、私の出した結論としては
１）ＭＯＤＥＬ バックエンドのＰＣ、共通ドライブに設置したＡＣＣＥＳＳテーブル
２）ＣＯＮＴＲＯＬ ローカルＰＣにインストールしたＡＣＣＥＳＳ（フォーム、クエリ）
３）ＶＩＥＷ ローカルＰＣにインストールしたＥＸＣＥＬ（グラフ、ピポッドテーブル）
という構成で、プログラムを作るのがよさそうだ・・・
最近の流れ
ＭＳはＥＸＣＥＬにパワークエリと、パワーピボットなるものを入れてきた。
この流れは、ＣＯＮＴＲＯＬ、ＶＩＥＷをかなりＥＸＣＥＬ側に強化してきたような感じである。
しかしながら、いっぽうでパワークエリ、パワーピボットは、ＶＢＡでは扱えない。。。。
この流れが意味することは、ＥＸＣＥＬアプリケーションは、
もはやプログラミング可能なフレームワークとしてのニーズが
なくなってくるのではないだろうか？
で、思うところとしては、やはりＡＣＣＥＳＳ側をゴリゴリやりたくなってきた。
データベースは、別にアクセスじゃなくても、ＳＱＬサーバーとかＯＤＢＣでつなげばいいから
あとフォーム作成の容易さや、ＳＱＬやリレーションのＧＵＩが秀逸なので、
これは他のフレームワークには無い利点である。
足りないと思うのは、唯一グラフ表現のチープさである。
だから、ＪＡＶＡＳＣＲＩＰＴのＧＵＩライブラリを駆使して、
ブラウザ側で表記できれば、すんなり行くような気がする。
欲しいなと思う機能は、ＡＣＣＥＳＳのフォームを、ブラウザ側のＪＡＶＡＳＣＲＩＰＴから呼び出すか、
そっくりそのまま、フォームをブラウザベースで書き換えてくれるようなトランスレータだ。
これができれば、まだまだＶＢＡでのアプリ開発の可能性は
無限に広がるような気がしている。
（そうこうしているうちに、ＪＡＶＡＳＣＲＩＰＴ学習が進んだ暁には、
ＭＯＤＥＬもＮＯＤＥｓ．ＪＳでやれたりするんだろうけど。。。
そのときには、ＭＳからは離脱していくんだろうなあ）
そんな流れもあるので、ＭＳはＶＳＣＯＤＥやＡＺＵＲＥにも力を入れ始めたんじゃないかなあ
と勝手に思っている