CakePHPを使ってみた - kouki

じっくり使い始めて1ヶ月くらいたちました。
CodeIgniterとKohanaでいらいらさせられたFormヘルパーとバリデーションについてはまずまず気に入って使えてます。だが、どうしてもモデル周りの設計(というか全体的なデータの扱い)がよくないと思えてきた。開発効率がすごくあがったとかの話もあるようだがホントなのだろうか？　以下、現時点での考察です。

DBのテーブルに強く依存した設計

CakePHPはDBのテーブル構造にとても強く依存した設計になっています。1テーブル=1モデル=1アクションというシンプルな構造がCakePHPで想定されている設計のようです。デフォルトの規約でコントーラはコントーラ名から自動的に利用するモデルを決定します。またモデルはアクティブレコードなので1モデルクラス=1テーブルという構成になっています。
また、Formヘルパーもモデル名を指定するようにできていて、1モデル=1フォームのような構造でアプリケーションを構成することを想定した設計になっているようです。バリデーション定義もモデルに記述するので、POSTされる入力データ構造もまたモデルの構造(=テーブル構造)を前提とします。
もちろんこれら規約から外れた実装をすることもできますが、コードが複雑になるという弊害がもたらされます。

何がよくないのか？

上記のような構造なので、CakePHPはクライアントがHTTPリクエストを発行してレスポンスを受けるという1プロセス全体を通して、テーブル構造をそのまま反映したデータ(モデル)を利用します。そのための便利な規約やAPIをフレームワークが用意しています。
しかし実際にアプリケーションを実装すると、Webアプリケーションの各層で利用されるデータはそれぞれ微妙に異なることが多々あります。たとえば画面層でのデータにはデータソース層(=DB)にはないデータを使用することがあります。内部処理を分岐させるための(保存する必要のない)制御パラメータなどです。
CakePHPはこのようなデータの違いをうまく吸収してアプリケーションの各層を実装するのが困難な設計になっています。MVCによる見通しのよい構造はできていますが、モデル、ビュー、コントローラそれぞれで利用される各データ構造は常にDBのテーブルに縛られているのです。
JavaでWebアプリを実装していたときのことを思い出すと、テーブル構造はDAOによって論理上完全にビジネスロジックや画面からは隠蔽されていました。ビジネスロジックや画面はそれに必要なデータのみを扱えばよかったのです。（そのかわり各層でのデータ受け渡しなどの処理を実装する必要はあった）

要するにCakePHPはごくシンプルなアプリケーションを作成するのに最適な規約とAPIを用意しているが、複雑なビジネスロジック(モデル)の実装を困難にしている、というのが現在の印象です。そして大抵のWebアプリはCakePHPが想定しているほど「ごくシンプル」ではないと。
画面とDBでデータのミスマッチがあるとき皆どうしてるのかなあ。