2009年3月24日火曜日

コントロール、サービス、ドキュメント

週末にPythonと格闘してGoogle App Engineの金型をつくったので、これをベースにSimpleModelerのGoogle App Engine生成器のリファインを開始。

Ruby on Rails、Grails、Google App Engine、Google App Engine Oilを一通り調べて、これらのWebフレームワークが共通して持っている問題だと思うのは、MVCのコントローラからPSM(Physical Data Model)をダイレクトにマップしたモデルを直接触る構造になっているということである。もちろん、アプリケーションが意識すればそういう構造にしないことも可能だけれど、自動生成されるCRUDのコントローラはPSMモデルを直接操作する構造になっているし、色々なクックガイドのサンプルもそういう形になっている。
この方式が問題なのは、UIのコードがデータベースのデータ構造を直接意識してしまうことと、アプリケーション・ロジックがUIコードに断片としてばら撒かれてしまう点にある。また、UIデザイナとアプリケーション・プログラマの仕事が分離しづらいという問題もある。
この問題はかつてのCS(Client/Server)で既知のものであり、CSシステムの保守や拡張を大変にしている。
作っているプログラマは楽だけれど、その後、高コストになるアーキテクチャなのである。

もちろん、作り捨てで拙速を重要視するタイプのシステムはこの戦略が合っているわけだけれど、"持続性"が大事な企業アプリケーションではそういうわけにはいかない。

この問題を解決するためには、アプリケーション・ロジックをコントローラから分離し、サービスとして独立したジュールとして作成。コントローラからはサービスを呼び出すという構造にするのがよい。
この時、コントローラからサービスを呼び出す際には"構造を持った値"によってパラメータの受け渡しをすることになる。この目的でSimpleModelingが用意しているモデル要素がdocumentである。

以上のような理由によって、SimpleModelerでは、MVCのコントローラとアプリケーション・ロジックを分離して、アプリケーション・ロジックをサービスとして部品化する構造のアプリケーションを自動生成を指向している。このアプリケーション・アーキテクチャでは、ドメイン・モデルの操作もできるだけサービスとしてカプセル化する。

昨日の作業で、この方針に沿ったそれなりのコードが出てくるようになった。
今朝から、Google App Engine SDK上で生成されたコードのデバッグとチューニング。かすかに動き始めたようである。

0 件のコメント: