Webフレームワーク

Google App EngineのWebフレームワークとGoogle App Engine Oil（GAEO)を調査している。
GAEOでURLとMVCの実装を:controller/:actionのコンベンションに結び付けている部分が面白い。一種のリンカですね。
本家のRuby on Railsは:controller/:action/:id.:formatというコンベンションのようだけれど、こういったURLと実装の動的リンク機能(何か名前がついているんだろうなー、以下ではURLルーティングと呼ぶことにする)がRuby on Railsの柱の一つであり、これをGoogle App Engine(GAE)で実現しようとしているのがGAEOということである。
GAEOのCRUD VC自動生成はまだまだ発展途上だと思われるけれど、このURLルーティング機能は現時点でもかなり使える。

と、ここでSimpleModelerのGAE生成器だけれど、GAEOに全面依存するのもリスクがあるので、gaeサービスではGAEのみを使うようにしようと思う。URLルーティングも簡単なものを自前で実装することにする。
これとは別にgaeoサービスでは、GAEOのURLルーティングを活用したプログラムを自動生成することにしたい。

調べてみるとWebのこのあたりの技術はなかなか面白い。こういった処理を実装する場合、メタ・プログラミングを使ってコンベンションによる動的リンクが非常に有効なのでPythonやRubyのような動的言語が大人気なのもよく分かる。
ただ、こういったWeb MVCの実装は、自動生成の格好の対象であることも感じた。
単純な繰り返しのプログラミングは、コンベンションと動的リンクで解決することも可能であるけれど、プログラムの自動生成で解決することも可能である。
プログラムの自動生成をするのであれば、ターゲットのプログラミング言語は静的型付のものでよい。つまり、自動生成を前提にするとテーゲット言語はJavaのみでも、Ruby on RailsやPython Djangoと同等のWebアプリケーションの開発効率が得られると思われる。
開発言語がJava指定の案件でも、Ruby on RailsやPython Djangoと同等の開発効率が得られれば魅了的である。

そうはいっても、RubyやPythonを主力言語として開発している人がわざわざJavaをやるというのも考えにくいので、結局の所、色々な言語の色々なWebフレームワークが並存することになるだろう。顧客が指定するWebアプリケーションの言語やフレームワークも多極化することになるだろうから、どのような組合せであっても対応できるのが開発者側のスタンスとしては望ましい。
こういったニーズに対してSimpleModelerのようなモデル・コンパイラは有力なソリューションである。

今回、Webフレームワークを調べてみて、SimpleModelerでかなりの部分を自動生成できるように感じた。ただし、ユースケースやドメイン・モデルから自動生成できるという意味ではなくて、システム・モデルとして画面遷移モデルなどの専用PIMモデルを定義すればである。
Webのフロントは開発工数も大きい上にバグの出やすいところでもあるし、要件定義から実装までの各段階で試行錯誤が必須の部分なので、PIMモデルからの自動生成ができれば、その効果は計り知れないだろう。
SimpleModeler的には、Scala DSLで定義した専用画面遷移モデルから、画面遷移図と各種Webフレームワーク向け実装の自動生成の機能ということになる。画面遷移モデルとドメイン・モデル、ユースケース・モデルとの連携は確保すれば、上流モデルからWebフレームワーク向け実装まで一気通貫で開発することができる。
GAEが一段落したら、SimpleModelerをそちらの方向に延ばしてみようかな。