Excel
access

MS(EXCEL,ACCESS)のアプリケーションを作っていて、

MVCというものに当てはめるとどうなるのかを考えてみた。

1)ACCESS

 アクセスはデータベースアプリケーションである。

 アプリケーションの中には、テーブル、クエリ、フォーム、レポート、マクロがある。

VIEW) フォーム、レポート → これは確実にビューでしょう。

MODEL) テーブル → データベースの中身なのでテーブルはモデルだろう。 

              SQLを処理しているACCESS本体もモデルということになる。

CONTROL) フォーム、クエリなどもコントロールだろう。

         マクロ、イベントプロージャは、用途によってはコントローラということになるかな・・・

2)EXCEL

 エクセルはどうだろうか?

 エクセルの役目は、グラフを書いたり、シートにデータを入れたり、ピボットを計算したりすることになる。

 これはちょっと難解だ・・・

VIEW) グラフ

MODEL) シート、シート関数

CONTROL) VBA

さて、ここまで書いたのには、それなりに理由がある。

ACCESSもEXCELも、半ば完成しているアプリケーションなので、

これはプログラミングからの観点からは、一種のフレームワークと見なせるのだ。

であれば、VBAのプログラミングでは、ACCESS,EXCELの良いところだけ使って、

あとは、プログラミングで補ったらどうかなと思うのである。

つまり、私の出した結論としては

1)MODEL  バックエンドのPC、共通ドライブに設置したACCESSテーブル

2)CONTROL  ローカルPCにインストールしたACCESS(フォーム、クエリ)

3)VIEW   ローカルPCにインストールしたEXCEL(グラフ、ピポッドテーブル)

という構成で、プログラムを作るのがよさそうだ・・・

最近の流れ

MSはEXCELにパワークエリと、パワーピボットなるものを入れてきた。

この流れは、CONTROL、VIEWをかなりEXCEL側に強化してきたような感じである。

しかしながら、いっぽうでパワークエリ、パワーピボットは、VBAでは扱えない。。。。

この流れが意味することは、EXCELアプリケーションは、

もはやプログラミング可能なフレームワークとしてのニーズが

なくなってくるのではないだろうか?

で、思うところとしては、やはりACCESS側をゴリゴリやりたくなってきた。

データベースは、別にアクセスじゃなくても、SQLサーバーとかODBCでつなげばいいから

あとフォーム作成の容易さや、SQLやリレーションのGUIが秀逸なので、

これは他のフレームワークには無い利点である。

足りないと思うのは、唯一グラフ表現のチープさである。

だから、JAVASCRIPTのGUIライブラリを駆使して、

ブラウザ側で表記できれば、すんなり行くような気がする。

欲しいなと思う機能は、ACCESSのフォームを、ブラウザ側のJAVASCRIPTから呼び出すか、

そっくりそのまま、フォームをブラウザベースで書き換えてくれるようなトランスレータだ。

これができれば、まだまだVBAでのアプリ開発の可能性は

無限に広がるような気がしている。

(そうこうしているうちに、JAVASCRIPT学習が進んだ暁には、

MODELもNODEs.JSでやれたりするんだろうけど。。。

そのときには、MSからは離脱していくんだろうなあ)

そんな流れもあるので、MSはVSCODEやAZUREにも力を入れ始めたんじゃないかなあ

と勝手に思っている