自分的Best

Coldfusion

ColdFuxionMX（取り合えず７）の開発モデルについて、自分なりのベストな構成を忘れても良いようにメモ。


一部まだ課題はありますが、MVCモデルを採用します。

レイヤ別の役割：Model

CFコンポーネント（拡張子cfc）で実装します。ここでCFMXの特性から、Daoを切り出してもあまり大きなメリットが得られるとも思えない為、DomainModelで実装するとSQLなども含めて非常に巨大化したコードを書く羽目になるので、Service単位など適度なサイズで取り纏めながらTransactionScriptで実装するのが良いように思います。
ただし、このあたりは業務ロジックの全体のサイズとで適切に判断が必要。

レイヤ別の役割：View

拡張子cfmのいわゆる普通のCFMXの実装です。
Strutsでも同じなのですが、アプリケーションサーバに隣接するレイヤはどうやっても泥臭くなります。アプリケーションサーバの仕様に拘束されてしまうためで、これはもう仕方が無いと割り切ってしまいます。
具体的には、表示用CFMファイル（View用）に、HTMLと表示に用いるためのCFMLを実装しますが、それらに加えて表示情報を取ってくるためのクエリも実装してしまいます。これは、例えばtableタグを使った表を作る為のクエリは、tableタグの近くにあった方が分かり易いと思うからです。ただし１点注意したいのは、極力ViewからModelは直接参照させないようにする、ということです。これをしてしまうとModelの影響範囲があまりに多岐にわたってしまい、影響度を把握できなくなってしまいます。

レイヤ別の役割：Controller

次いでControllerですが、これもcfmファイルとして実装します。View用のファイルと違いこのController用ファイルはイベント・ハンドラとして使うため、HTMLが実装されることはありません。Submitを受け付けた後は、遷移先を決定する上で必要な判断をModelを使って判定する、といった実装をしておきたいところです。そして判定結果はcfincludeまたはcflocationでリダイレクト→View用のファイルを表示させる、といった手順となります。

課題がある、といったのは、このController用ファイルでcfincludeまたはcflocationを使って画面遷移を制御しますので、cfincludeを使用した際、viewとcontrollerの配置フォルダが異なる場合、URL崩れが発生してしまいます。が、前述の通り泥臭くなるのは覚悟の上ですので、このまま実装します。

全体の構成について（＋課題など）

このような構成にしておくことで、私は以下のようなメリットがあると考えています。

  • Model部分をMockUpしておく事で、View/ControllerはCFMLを使った動的なプロトタイプをCFMLの特性を活かしてさくさく実装していける。（Agileなプロジェクトでは重宝すると思います）
  • Model部分を切り出しておく事で、UnitTest/RegressionTestが自動化できる（可能性が生まれる）。→ただし、JUnitのTestCaseにあたるモジュールは１から自作する必要がありますし、その実行もブラウザ経由になります。
  • Model/View/Controllerとそれぞれが役割によって分割されるため、変更を加える際は「修正」のほかに「新規のものに差し替え」という選択肢を考えられるようになります。（過去自分が主張した「修正するより作り直す方が早いかも知れない実装」を意識しています）


反面、以下のような課題も残ります。

  • 前述の「URL崩れ」が発生する。
  • 複雑な画面の場合、HTML-CFML-SQLが混在する実装が出来上がる。（共通部分はインクルードできるように構成するなど工夫が必要）


このモデルに最適なシステムのサイズとか、ビジネスユースな要素も含めて、今後機会があってなおかつCFMXに対する興味が再び私に戻ってきていれば実地検証をしてみたいところです。