>>549
必要なときにつけたりはずしたりする方法は、何度も既出

>>548

だめなのか？

>>546
なんでモデルでやるの？そのメリットは？

>>553
もちろん、直接関係が無いモデルは別々に
アクセスするよ。

モデルというか処理の内容から考えて
一つであるべきと思う場合は一つのモデルでやる。

あと、トランザクションの為のメソッドが
モデルにあることも興味深いよね。

一連関係ある処理は一つのモデル内で完結させるものと
考えると、なるほどと思わない？

>>546
モデルは複雑にすべきじゃないよ。な中規模設計したとき
アソシエーションで必ず問題起きそう

>>555
その意見はわからないでもないが、

普通にRDBMSを正規化したとき
そういう関連（リレーション）は出来るもんなんだが・・・

RDMSを正規化すると複雑になってしまう。それがいやだから
それを解決する為に、O/Rがあるんだと思うぞ！

>>546
ページ数が増えたとき、コントローラを増やすことができるけど
コントローラが増えた分モデルを増やすこと出来ないよ。
ひとつのモデルに書くコードが恐ろしく増えるね

また例の馬鹿か？

> コントローラが増えた分モデルを増やすこと出来ないよ。

言っている意味が、よくわからないんだが・・・

例えコントローラが無くてもモデルは作れるし、
一つのコントローラで複数モデルを扱うことも出来るんだが？

全てはコントローラに処理を詰め込み過ぎたscaffoldが悪い。
あれがアフォに勘違いを植え込む。

うーん、自動生成のコードとしては、これしかやりようがない所もあるのだろうけど、
コントローラに処理を詰め込みすぎというか、モデルに処理が何も無いのが
いけないんじゃないかな？

あれじゃ、単にテーブルに直接アクセスするネイティブな関数の
代わりのクラスにしか見えない。

一番、プログラマがいろいろ書くべきなのはモデルなのに。
逆に言えば、いろいろ書かないといけないものだからこそ
自動生成ではモデルに何もないんだろうね。
でもサンプル程度はほしいかも。

cakephpで作られたオープンソースみても
モデルで書かれてる処理はバリデータ関係の関数しかないんだけど

http://code.google.com/p/openflp/

ん？なんかいろいろゴチャゴチャしてきたけど、結局俺が主張してたことは正しかったのか・

「複雑な一連の処理」とかビジネスロジックとかって、たとえば俺の場合は
　・①日足の株価を取得してRSIを計算する
　・②与えられた条件引数に該当する銘柄の証券コード配列を取得（スクリーニング）
　・③現在の株価を受け取り、あらかじめ計算しておいた目標価格の条件を満たすか判別
　　　⇒・更に条件を満たしていれば、買い/売り注文をWEBサービスに投げる処理も「証券会社モデル」（仮称）というDBと連携しないモデルを作成して、HTTP(S)で注文するメソッドを書いてる。
　・④現在の株価を取得する（楽天証券のRSSをDDE接続経由で呼び出すモジュールを別途使用）
みたいなアプリが持つほとんどの主要処理を言ってて、これらをモデル（またはビヘイビア）に記述するべきと思うのです。

逆に言えばコントローラは、
　・④の「現在の株価を取得する」メソッドからの返し値をそのまま③「株価と目標を評価し、注文する」メソッドに引渡し仲介する
　・ビューからリクエストがあった①などの計算処理をモデルメソッド①に引き渡す
　・スクリーニング対象銘柄の証券コードリストを取得し、そのまま②のスクリーニングメソッドに引き渡す。
くらいのことしかしていない。人間の世界でいうと「仲介人」かと。

>>565
お前の目は節穴か・・・

ってかこのソースあまりいいとは思えないな

じゃあ本家railsのソースコードみせてやる

コントローラに処理を詰め込みが正論か非か
オープンソース見れば、すぐわかることだからな

オープンソースといってもその質はピンキリだから

> じゃあ本家railsのソースコードみせてやる
おいっ！ railsはフレームワークだ。
もともとビジネスロジックは含まれてない！

>>567
全部コントローラで出来るし
それをCakePHPでやる意味がわからんｗ

>>573
あー、「全部コントローラで出来るし」って言ってる時点でプロフェッショなるじゃないことが確定www
議論しても理解できないんだろうな、「できる/できない」ということと「（プロとして）やるべき/べからず」
といった本質的な点をwww

コントローラでも全部やろうと思えばできることくらいわかっとるわいｗｗｗ

>>574
CakePHPでやることじゃないことは確かｗｗｗ

ビジネスロジックはモデルに集約すべき
議論としては面白い
俺もその辺気になってた


まあ俺はbakeしたコードの拡張から入ったクチだから全部controllerに書いちゃうけどなｗｗｗ

>>576
俺もコントローラに書いてしまったけど、
作り続けていくうちに、なんか無理が出てくるんだよ。

なんでこんなに作りづらいんだ？って思っていたときに
このスレにあった、ケーキの絵。あれで悟りを開けた気がする。
あぁモデル中心でやればいいんだって。

>>577
その絵ってどれ？

>>562
モデルに書けって言うけど、何を書くの?
関数で書けばいいの?モデル内のメソッドとして?

>>565
の言うとおり、実例も無いし具体的なメリットが分からない。
今のところテストが楽って事はなんとなく分かった。

>>578
これの3ページ目
http://cakephp.org/files/OCPHP.pdf

> 関数で書けばいいの?モデル内のメソッドとして?

モデル = ビジネスロジック用のクラス
なんだから、言うまでも無くメソッドだろ

>>580
ありがとう，でもコントローラーよりモデルに重点おけよという一言で済む話かｗ

>>581
そうすると、どう幸せになれるわけ?

>>583
どう幸せになるかではなく、
どう幸せになりたいか。

貴方はプログラミングする上で、どうなったら幸せだと感じる？

railsはコントローラーに重点を置くようになってるのではなぜ？

>>574
自分の安価間違ってね？516と522で筋が通ってない

>>585
railsでもモデルが一番重要なものですよ。

モデルが一番重要なんてCakePHPだけの話
松本に話したら鼻で笑われたよ

松本といっても鼻の長いゾウをキャラクターにしている会社の松本だけどなｗ

でもキリンさんも好きなんだろ？

ビヘイバ話はおわったのか？

Model は特定の環境に依存しない処理を行う部分である。

たとえばの話なんですが、
１．フォームから画像ファイルをアップロード
２．アップロード結果・画像ファイルの不正検知
３．２が成功時、元画像名をmd5したものをuploadsフォルダに保存
４．３のファイル名をimage_fileカラムに格納
という一連の処理があったばあい、
今現在はコントロールとコンポーネントに書いてますが、
モデルとビヘイビアに書くとしたら、
２->バリデータに記述
３->ビヘイビア
４->モデル
という感じなんでしょうか？

ビヘイビアて1.2からだろ、
最初から無いってことは必要性が薄いてことだよな

ソースが読みやすければコントローラーで全部書いてもいいし
モデルに書いて読みにくくなるなら、書かない方がいい
結局はソースを読みやすくするために分けてるだけの話

画像アップロードできるビヘイビアあるよ。
正確には画像を保存できるビヘイビアだけどね
http://bakery.cakephp.org/articles/view/actas-image-column-behavior

結局はソースを見やすくする為にある。
一番見やすいソースとは、なるべく何も書かないこと。

画像をアップロードして保存というのは、本質的には
テーブルに画像フィールドを作ってそこに格納することと変わらない。

だからフィールド追加作業以外は、一切処理を変更しないで
作れるというのが一番理想的。

ビヘイビアを使えば、>>596のようにActsAsにわずかなフィールド情報を
設定して終わりだけど、その他の方法でここまでスマートに作れるかな？

>>596-597
ありがとうございます。
こりゃ1.2にチャレンジしなきゃだな

>ビヘイビアて1.2からだろ、
>最初から無いってことは必要性が薄いてことだよな

正確には1.1の頃からビヘイビアのディレクトリは用意されてたんだよな。
おそらく必要性はあったのだけど、1.1.xのステイブル版までに実装できなかっただけなのでは？

railsにはビヘイビア相当になるものが無いんだが、どうして