元スレ【PHP】フレームワーク CakePHP　3ホール目【本命】

php覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

551 = :

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

552 = :

>>548

だめなのか？

553 = :

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

554 = :

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

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

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

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

555 = :

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

556 = :

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

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

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

558 = :

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

559 = :

また例の馬鹿か？

560 = :

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

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

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

561 = :

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

562 = :

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

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

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

565 = :

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

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

567 = 513 :

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

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

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

568 = :

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

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

570 = :

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

571 = :

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

572 = :

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

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

573 = :

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

574 = 513 :

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

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

575 = :

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

576 = :

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

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

577 = :

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

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

578 = :

>>577
その絵ってどれ？

579 = :

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

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

582 = :

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

583 = :

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

584 = :

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

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

585 = :

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

587 = :

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

588 = :

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

589 = :

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

590 = :

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

591 :

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

592 = :

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

594 = :

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

595 = :

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

596 = :

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

597 = :

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

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

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

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

598 = :

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

599 = 591 :

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

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

600 = :

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