ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)

2007年~2011年ごろまで はてなダイアリー に書いてた記事を引っ越してきました。

Cakeの押しつけルールから解放されるためのメモ

将来自分が嵌っていたであろう箇所を先につゆ払いし、またそれをふまえた所感も激しく同感できそうだったので
c⌒っ*゚ー゚)っφ メモメモ

独特のモデルの性質と、コントロールの規約から解放されたい。余計なルールはムシして、わかりやすいように使っちゃうことにしました。規約を捨てたほうが使いやすくなる、という場合もある。

http://blog.takeda-soft.jp/blog/show/192

CakePHPが独特なのはORMというかDAOレベルの実装を自前で用意していて、しかもそれがController/Model相当と密に結びついている点だと思います。さらにinputタグのname属性の規約的に、Helper(=View)とも結びついていると考えられます。
この点に対してどういうスタンスを取るのか、を早期に見極めることができる、あるいはこうしたCakePHPのクセ(多分、根っこの哲学と結びついているので引きはがすのは無理だと思う)を認識できるか、で、CakePHPとうまくつきあうことができるかが決まると思います。

っつーか、そこまでしてSQL書きたくないのかね?
CakePHPのDB部分、生理的に吐き気を催すくらい受け付けられないのだけれど。自分自身、MVCが密にDBと絡み合ったオレオレフレームワークを作ったことがあり、実際それで、後のメンテナンスや拡張性がぼろぼろで痛い目見たので、どうにも、CakePHPの癒合は受け付けられない。
今は「お試し」なのでCakePHPのModelを使ってみているけど、仕事で本気でやるのであれば、CakePHPのModelは使わずに、ADODBとかMDB2とか(PHP4だから・・・)、あるいは利用するDBMSのI/F関数を直に呼ぶ、そのプロジェクト専用のDAOを用意すると思う。

symfonyはDBレイヤーとWebAppのコントローラ部分は切り離されていて、確かにPropelとかでCRUD画面を生成できるけど、それは単に、綺麗に切り離されたPropelとコントローラを組み合わせたコードテンプレートを生成しているだけなので、決して根本や、哲学レベルで癒合を前提としているわけじゃないし。