2005年07月04日

Webフレームワークを考える2

以前「Webフレームワークを考える」を書いてから、J2EEやCatalystの構造を勉強してみて、改めて自分なりのフレームワークを考え直してみた。

※改めて書くほどの事ではないが、J2EEやCatalystを再定義するほど私のスキルは高くないし、このエントリ自体が自分用の脳内メモなので、世間の常識とは外れているかもしれない。免疫のない人はご注意を。

まず、重点項目のリスト。

  • DaOは他システム(フレームワーク外)からもアクセス出来るように、インターフェイスを決めてカプセル化する
  • コントローラには必要以上に機能を与えない
  • 分業化とユニットテストを可能にするため、Action (Model) とViewを完全に分離し、混同させない
    例えば、Action側でViewで使うデータを用意するような処理は抑制する。
  • 入力 (CGI.pm) と出力 (HTML::Template) はフレームワークで用意する
  • Actionの特定 (ページの推移) を PATH_INFO に縛られたくない

そして、フレームワークを作成する、そもそもの目的。

  • 標準外のモジュールをあまり必要としない構成にしたい
  • (フレームワーク自体の習得も含め)Webアプリケーションの開発期間を短縮したい
  • クラスの過剰な継承を防ぎ、実行速度を稼ぎたい
  • 高度で先進的な技術の追求よりも、パフォーマンスとメンテナンス性に重点を置きたい
  • Perlのスキルがそれほど高くなくても、ModelとViewの開発とメンテナンスが可能

とうわけで、私の脳内メモ。(私以外の人には訳わからない図だと思うが、ご容赦を)
詳細モデル図

Actionごとに必ず対応するViewが必要となる。
Viewが必要とするデータは直接DaOから取得する。
Modelの役割は基本的にデータの更新であるため、ActionによってはModelが必要無い場合もあり得る。


そして、実際のフレームワークの構成を考えてみた。
webapp_plan1.png

上記の脳内メモの“Action”で扱う処理手順のコードをModel内に含むことにして、ActionごとにModelとViewが1対1で対応するようにする。
ただし、Model (内のActionコード) がViewを呼び出すのではなく、Modelの処理が終わったら、フレームワークがViewを呼び出す。


現時点での計画はこんなところ。
ModelとViewの分離を優先させたため、ControlとModelが融合しかかっていて、パッと見はCatalystとあまり変わらないモデルになったかもしれない。

UMLを勉強して、この“なんちゃってモデル図”をオブジェクト図やクラス図で表せるようにならないといかんかなぁ…。


Catalystは知れば知るほど魅力的なフレームワークだが、用途によっては相容れない部分もある。今後プライベートで何か作るときには使ってみたい。

Posted by SYN at 2005年07月04日 21:50 for Develop | TrackBack
Comments