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

【PHP】フレームワー� ..

413:nobodyさん
08/03/28 11:13:12
>>411
自治厨乙。
だいたいにして、IDなんていつでも変えれるんだから意味ないじゃん。

414:nobodyさん
08/03/28 11:14:01
ろくでもないレスは無視するかマナーをもって
訂正を促すのが良い返答の仕方だよ。

415:nobodyさん
08/03/28 11:14:44 q/btZ3WH
>>413
やってみなきゃわからないじゃんｗ

416:nobodyさん
08/03/28 11:17:51
>>415
どんだけ必死なんだよｗ

417:nobodyさん
08/03/28 11:57:59 anJTbKap
>>409
もちろん速度を重視しなくてはならない場面ならば専用メソッド内でSQLを書きます
しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると
フレームワーク自体に手を出して最適化させた方がコスト的にベターかなと思います

>>403
複雑なアソシエーションのパターンが出来上がってる時はView使った方がいいですね
今ふと考え付いたのですが、結合済みの仮想テーブルを作って、それを元に
CakePHP側のモデルを構築するアプローチは面白いかもしれません

#仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが

418:nobodyさん
08/03/28 12:20:53
>>417
負荷を考えるならフレームワークやめろ
CakePHPなんてのは、どうでもいいクライアントに高速納品するための道具てことに気づけよバカ

419:nobodyさん
08/03/28 12:26:48
>>417
今頃フレームワークの評価とか手を出すとか、どんだけ遅れてんだよ
この業界は進歩が早いの知ってる？

420:nobodyさん
08/03/28 12:43:39
>>417
> 結合済みの仮想テーブルを作って、それを元にCakePHP側のモデルを構築する
view作ればって言ったのはそういうこと。
面白いかどうかはおいといて、現状の打開策としてはアリかなと思うわけです。

> 仮想テーブルへの更新作業はDB依存のため怪しい臭いはしますが
このDB依存は仕方ないと割り切ればいいんじゃないかな。割り切れるところだと思うし。

421:nobodyさん
08/03/28 12:49:51
>>417
やる前にあれこれ聞かずにやってみろよ
こんなとこで解決できれば苦労しねーよクソが

422:nobodyさん
08/03/28 12:53:20
評価なんてソース解析して自分で実際にサイト構築しないとわからねーよ
やってくうちに想像しない難点が沢山でてくるよ

423:nobodyさん
08/03/28 13:01:42
>>417
速度重視とか柔軟性考えるならＣＩにしろや

424:nobodyさん
08/03/28 13:04:47
CakePHPを最適化させにくいフレームワーク
最適化したいならＣＩスレにいって、このスレからでていけや

425:nobodyさん
08/03/28 13:28:19
>>420

426:nobodyさん
08/03/28 13:34:05
っていうかJOINにならないというのは
どのフレームワークでも同じこと。
CIでもSymfonyでもRubyOnRailsでも同じだよ。

特にCIは最悪だね。いろんな意味で。
ここではすれ違いだから言わないけど。

427:nobodyさん
08/03/28 13:40:13
>>426
どのフレームワークも同じなら軽量でサクサク動作するＣＩの方がマシ

428:nobodyさん
08/03/28 13:44:02
>>417
> しかし、上記の様にシンプルなアソシエーションすら動作が怪しいとなると

シンプルではないよ。

CakePHPでもその他でもそうだけどO/Rマッピングというのは
従来の表形式の使いづらいリレーショナルデータベースを
高レベルに扱いやすく使えるようにするもの。

リレーショナルデータベースを基本に設計されたものではなく
より理想的なオブジェクト指向風なデータ構造をもとに設計されたもの。
だからいろんな取り出し方ができる出来る柔軟性がある。

たとえば、behaviorでデータ挿入・取り出し時に色んな処理をかませられる。

そういう柔軟性を持たせながらシンプルなSQLに置き換えるのは容易ではない。
不可能な場合すらある。

なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること。一日働いて3万円人件費をかけるのなら、
その3万円でスペックをあげたほうが総合的に考えてメリットが
高いという時代だから、今は。

429:nobodyさん
08/03/28 13:50:03
CIはデータベースを使わない。使う頻度が少ない場合にはいいけど、
データベースを使う場合、貧弱だよな。

あれならSQL直書きした方がいいってほどメソッドがアホらしいしｗ
なによりビヘイビアが無いのが一番痛い。

430:nobodyさん
08/03/28 13:50:47
>>428
なんでもかんでもパフォーマンスを気にして無駄なものを作るのは
初心者のやること

サイトリニューアルなど
既存ユーザーが多数いる自社製品ならパフォーマンスを意識する

431:nobodyさん
08/03/28 13:52:21
> 既存ユーザーが多数いる自社製品ならパフォーマンスを意識する
マシンスペックを上げろ

432:nobodyさん
08/03/28 13:54:32
>>429
複雑なアソシエーションはＳＱＬ直書きになるんならＣＩが理にかなってる

433:nobodyさん
08/03/28 13:55:17
複雑なものじゃなくてシンプルにしようと考えような。

434:nobodyさん
08/03/28 13:55:42
>>426
symfony(というかpropel)はJOINになる

435:nobodyさん
08/03/28 13:56:08
>>431
ユーザーが増えるたびに、どんだけマシンが必要になるんだよ

436:nobodyさん
08/03/28 13:56:12
JOIN使わないで一回一回よんでも
パフォーマンスはたいして変わんないんだけどなｗ

437:nobodyさん
08/03/28 13:57:04
>>435
ユーザーが増えると重くなるのはどれでも一緒ですが？

働いていない人は、人件費というコストを計算に入れないからなぁｗ
まあ、がんばれやｗ

438:nobodyさん
08/03/28 13:57:54
>>436
変わるよ　あほか

439:nobodyさん
08/03/28 13:57:57
ＳＱＬ直書きになる機会が多いならＣＩがいい

440:nobodyさん
08/03/28 13:58:21
O/Rというのはリレーショナルデータベースからの
脱却に意味があるというのに、今時SQLなんて低レベルなことやるかよｗ

441:nobodyさん
08/03/28 13:58:54
>>437
ずっと開発してるわけじゃねーからｗ
人件費とか１回ぽっきりやん

442:nobodyさん
08/03/28 14:00:15
複雑なＳＱＬならＯ/Rマッピング使えないじゃん
今のＣａｋｅＰＨＰなら
だったらＣＩでＳＱＬ直書きが最高よ

443:nobodyさん
08/03/28 14:03:25
>>437
重くなりかたが異なってくるんですが？

1回で済む処理を2回のクエリで行ってるとアクセス数が増えたときにクエリ発行数が大きく変わることがわかんない？
ほんとにプログラマなのか？まぁ、がんばれや

444:nobodyさん
08/03/28 14:05:37
ぷｗ頭固いな。mixiの話とかしらんのかいな

mixiでは”高負荷に耐えるためにJOINを使っていない”んだよ。

URLﾘﾝｸ(www.google.co.jp)

445:nobodyさん
08/03/28 14:07:29
>>442
使えていますが？ JOINが使われないってだけでしょうが。

パフォーマンスに問題が無い場所で、
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHPと、
SQLを書くのと同等の手間をかけなければならないCIでは
どちらが優れているかは言うまでも無く、CakePHPですね。

446:nobodyさん
08/03/28 14:08:18
>>441
マシンスペックを上げるのも一回ぽっきりですが？

447:nobodyさん
08/03/28 14:09:13
ビヘイビアがない時点でCIは糞ｗ

448:nobodyさん
08/03/28 14:11:24
>>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP

group byとかどうやんの？

449:nobodyさん
08/03/28 14:12:45
>>445
複雑なSQLを、SQLを書かずに作れる（買いても作れる）CakePHP

この発言無理がありすぎやろｗ

450:nobodyさん
08/03/28 14:13:42
>>444
あのさ、読解力なさすぎ。
「高負荷に耐えるためにJOINを使っていない」とは書いてない。

451:nobodyさん
08/03/28 14:14:14
結局アンチはいつものCI厨だったなｗ

452:nobodyさん
08/03/28 14:15:24
>>450
ではJOINを使わない理由になんて書いていますか？言ってみてください。

453:nobodyさん
08/03/28 14:17:30
>>452
スケールするためにデータベースを分割し、JOINが使用できなくなったから。

454:nobodyさん
08/03/28 14:20:13
スケールとはパフォーマンスをあげるということです。

455:nobodyさん
08/03/28 14:21:44
うん。だから？

456:nobodyさん
08/03/28 14:22:38
>>455
おまえの負けてことだよ

457:nobodyさん
08/03/28 14:24:15
>>456
あからさまにバカだな。論理的に考えられないんだな。

458:nobodyさん
08/03/28 14:24:38
>>447
1.1使ってる人は真性なる糞ですね

459:nobodyさん
08/03/28 14:25:14
高負荷に耐えられるパフォーマンスを作り出す為に、
データベースを分割してJOINが使用できなくなった。

負荷を考えるのなら、JOINなんかするより、
マシンに投資してデータベースを分割（当然マシンも増えているはず）して
アプリケーションで行ったほうがいいということです。

460:nobodyさん
08/03/28 14:28:55
>>457
さっきまでパフォーマンスの話してたやろうが
論理的な会話してないのお前だろｗ

461:nobodyさん
08/03/28 14:31:33
結局ＣＩが最強てことじゃんか

462:nobodyさん
08/03/28 14:37:17
CIはフレームワークを使っているとは思えないほど開発工数がかかる。

データベース部分は、SQLの単語（selectやfromやwhere）を
それぞれメソッドに置き換えて実行しないといけない。
なんとビックリｗ

だから糞。

463:nobodyさん
08/03/28 14:38:23
わろたｗ

$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);

$query = $this->db->get();

464:nobodyさん
08/03/28 14:38:41
>>459
ただ、「マシンに投資してデータベースを分割（当然マシンも増えているはず）して」が始めからできるわけじゃないんだよね。
だからSQL発行数も含め、パフォーマンスには常に気を遣うわけで。
mixiが今はソフトウェア側でパフォーマンスを気にしてないかっていったらそんなことはないし。

>>460
パフォーマンスの話してるよ。何言ってんの？
もう面倒だからお前いいよ。

465:nobodyさん
08/03/28 14:40:13
だからパフォーマンスを重視するところだけ
最適化して、あとは楽で速いコーディングをすればいいじゃんか。

パフォーマンスの基礎だよ？

466:nobodyさん
08/03/28 14:41:27
>>463
これいいね。わかりやすい構文だ
CakePHPの
find(null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,)
これに比べれば天と地に差

467:nobodyさん
08/03/28 14:42:45
>>466
引数の数を勝手に増やすなｗ

最後の引数の意味言ってみろよ。
いえなければ赤っ恥だなｗ

468:nobodyさん
08/03/28 14:42:48
>>464
おまえ誰だよ？トリップでも番号でもいいから付けろよｗ

469:nobodyさん
08/03/28 14:44:26
>>463はPHP4だと
$this->db->select('title');
$this->db->from('mytable');
$this->db->where('id', $id)
$this->db->limit(10, 20);
こうなります。

470:nobodyさん
08/03/28 14:45:17
>>464
名無しで必死にレスしてるようだが
名前に番号でもつけてくれないと
今までどんな発言してんかわかんないんだがｗ

471:nobodyさん
08/03/28 14:46:08
>>468
どうせトリップつけさせて削除しようって魂胆だろ。
そんな手に引っかかるか。ばーかｗ

472:nobodyさん
08/03/28 14:46:42
>>469
わかりやすくていいね、さすがＣＩ
ヌルヌルフレームワークとは大違い

473:sage
08/03/28 14:50:37 JUQ1v1x2
$this->flash で出てくるはずのページがIE6だと表示されん。ソースは吐かれてる。
ってことはUTF関係か。

474:nobodyさん
08/03/28 14:50:44
アンチレス繰り返してたら、えらい盛り上がってきた

475:425
08/03/28 14:54:55
すみません、途中投稿しました

>>420
その通りですね。同一アプリケーション内でDBをスイッチする事はありえないので
リスクとしては小さいため十分検討できます(一応、PostgreSQL使ってる方は注意です)

>>424
CodeIgniterもとてもいいフレームワークだと思います
ぜひその情熱で当該スレッドを活性化させて盛り上げて欲しいですね

>>428
確かにアソシエーションの自動判別が面倒(無理)という事情は分かります
面倒なSQLを叩かずオブジェクティブにデータセットを取得できる機能が
すでに実装されていているのですからそれを使うに越した事はありません
この辺りの実装はアプリケーション全体のパフォーマンスに影響するため
サーバ増設前の改良を十分に検討できる部分だと思います

476:nobodyさん
08/03/28 14:54:59
実はアンチを煽って盛り上げさせているというのはナイショだｗ
見ろ他フレームワーク（特にCI）の静けさを！

477:nobodyさん
08/03/28 14:56:44
>>469みたいなコードを書くぐらいなら
SQLをそのまま書いたほうがいいな。

478:nobodyさん
08/03/28 15:06:18
>>428
すみません
>>475の説明はちょっと意味不明ですね、スルー推奨です

479:nobodyさん
08/03/28 15:45:01
Ｃａｋｅは糞

480:nobodyさん
08/03/28 15:54:32
aki(ryが本出してるから糞

481:nobodyさん
08/03/29 07:40:57
あの本は確かに糞だったな

482:nobodyさん
08/03/29 09:07:16
あれは本当に酷かった

483:nobodyさん
08/03/29 15:28:58
文句だけは達者だな

484:nobodyさん
08/03/29 15:56:30
達者？

485:nobodyさん
08/03/29 16:10:19
このスレはいつも無駄に盛り上がるよな

486:nobodyさん
08/03/29 16:54:04
>>484
ゆとり乙

487:nobodyさん
08/03/29 17:43:56
>>486
ゆとり乙

488:nobodyさん
08/03/29 20:03:50
>>486
ゆとり乙

489:nobodyさん
08/03/29 22:04:16 t2qvxoud
CakePHPっていいフレームワークだよな

490:nobodyさん
08/03/29 22:08:25
ソース汚いけどな

491:nobodyさん
08/03/29 22:15:25
最高のフレームワークだね
完璧すぎる

492:nobodyさん
08/03/29 22:29:55
おまいらマインドマップ使ってる？

493:nobodyさん
08/03/29 22:57:31
30才過ぎるとマインドマップ使わないと
トイレ行った後とか今まで何考えてたかさえ忘れる

494:nobodyさん
08/03/29 23:43:43 VJRoSuRr
なんでマインドマップの話になったか分からないけど、自宅と会社のＰＣに
ＦｒｅｅＭｉｎｄインストール済み。

自宅ではCakePHPのシステム設計に使ってる。
ひとつずつやる事片付けて、終わったブランチに「レ」のアイコン付けるのが
楽しい。

495:nobodyさん
08/03/30 02:14:14
ＵＭＬはルール化した図解表現
マインドマップは自由な図解表現

496:nobodyさん
08/03/30 02:16:24
マインドマップで設計し形になったものをＵＭＬ化する

497:nobodyさん
08/03/30 02:17:48 xhO/sY7i
んで、UMLで書いた仕様書を投げ捨ててウンコする

498:nobodyさん
08/03/30 02:19:35
CakePHP使ってればUMLもマインドマップも必要ない

499:nobodyさん
08/03/30 02:26:47
作業途中に仕様的にやばい匂いがしたらマインドマップ使ってる

500:nobodyさん
08/03/30 02:31:49
問題を解決しやすい方法として
思ったことを、どんどん言葉として書き出す
わかってるからと頭の中でしまいこむと、全体的な解決図を結び付きにくくする

501:nobodyさん
08/03/30 02:45:33
難しい状況を言語化する能力がコミュニケーション能力での重要ポイントだと思う。
もっと言語化するクセつければ、コミュニケーション能力向上になるんじゃないかな

502:nobodyさん
08/03/30 17:27:12
render呼んだ後
すぐexit();
してる？

503:nobodyさん
08/03/30 20:27:27 3z+xm+ln
>>473
遅レスだが、ソースの頭にBOMを付けたら表示されるようになた。
が、viewのファイルは8Nで保存しておかないと、たまに悪さをするようだ。

504:nobodyさん
08/03/30 22:06:44
>>502
もっと常識的な質問たのむ

505:nobodyさん
08/03/31 10:30:36
>>502
してないよ

506:nobodyさん
08/03/31 10:59:21
>>505
コンポーネントでrenderを呼んだときは
exitしないとデフォルトのrenderが最後に読み込まれるよ

507:nobodyさん
08/03/31 11:00:31
cakePHPのテスト環境だけど
SeleniumとSimpleTestの組み合わせが最強？

508:nobodyさん
08/04/01 01:26:52 j0Vrw1hD
>>507
そっちのテストなら、ｾﾚﾆｳﾑだろうと手作業だろうとなんだって良くね？

ユニットテストをするのなら1.2から正式対応したSimpleTestって言うだろうけど。

ていうか、テスト駆動開発って面倒ですよね、時間がかかるけど出来上がり安定するのは確かだけど。

509:nobodyさん
08/04/01 01:34:29
正確にはテスト駆動じゃないけど、
ある程度の規模になったら、ユニットテストをやらないなんて
考えられないよ。

修正があるたびに同じテストなんてやってられない。
それこそ時間がかかる。

510:nobodyさん
08/04/01 02:09:46
Selenium IDE これいいね。これだけでも同じテストする必要がないし
なんといってもテストが楽

511:nobodyさん
08/04/01 12:33:08
Yahooが占いコンテンツ制作にCakePHPを採用

512:nobodyさん
08/04/01 20:20:10
なにこの寂びれぶり

513:nobodyさん
08/04/02 00:32:30 Ldo05SB7
んじゃ、おれがこのスレを潤わせてやるぜ
ビヘイビアって使ってる？

514:nobodyさん
08/04/02 00:38:10
>>512
荒らしが去ったので落ち着いただけ。

CakePHPを使って、ようやくサイトを公開できた。
思ったより使いやすいね、CakePHP。

515:nobodyさん
08/04/02 03:09:53
コンポーネント、ビヘイビア、ヘルパーの中では
ビヘイビアを一番使うな。

よくよく考えると、ソフトウェアの中心はモデル。
その中心の共通処理なんだからよく使うのは当たり前か。

516:nobodyさん
08/04/02 11:07:25
>>515
ソフトウェアの中心はコントローラー
なぜならコントローラーはモデルとビューにも指令を出すが
モデルは、たいていコントローラを介してのやりとりになるから

そういう考えで行けば、よく使うのはコンポーネントじゃないとおかしい

517:nobodyさん
08/04/02 11:18:11 Ldo05SB7
>>516
アフォがあらわれた

518:nobodyさん
08/04/02 11:57:50 KzinrGTW
findCount()で count(distinct hoge) を指定したいのですが
それは、findAll() でやるべきなのでしょうか？

519:nobodyさん
08/04/02 12:05:53
うん。アフォだ。ワロタｗ

コントローラなんて所詮インターフェースに過ぎんよ。
実際の処理じゃなくて、ブラウザから引数を受け取って
それを少々加工してモデルに渡す。
またモデルから受け取ったデータを少々加工してビューに渡す。

流れとしてはこんな感じだね。

「ブラウザ」→「コントローラ（加工）」→「モデル（実際の処理）」→「コントローラ（加工）」→「ビュー（HTML出力）」

っていうか、このように作らないとテストがしづらいったらありゃしない。

SeleniumやCakeWebTestCaseがあるとはいえ、
コントローラを操作してのテストでは範囲が大きすぎる。
もっと小さな範囲でテストできるようにしないといけない。

一番重要な処理を最小限の大きさ（なるべく他に依存しない）で
テストすること考えれば、自然とこうなるはず。

520:nobodyさん
08/04/02 15:46:57
ガソリン安いな～
これほど自民党の一党独裁の問題点が分かりやすい現象は無いなw

521:nobodyさん
08/04/02 16:07:32
>>519
そうなんだ。だから本にもモデルのテストの方法しか書いてなかったんだ。
モデルよりコントローラーをテストしたいんだけど・・・ってずっと思ってた。

ということは、僕のプログラムの組み方がよくないんでしょうか。

522:516
08/04/02 16:33:04 Ldo05SB7
>>515,>>121
さきほどはアフォと一言で片付けてしまって申し訳ない、2ch流の愛情表現だと思ってくれ

で、>>519のいうとおりアプリケーションの中心となるビジネスロジックについてはコントローラなどでは
なくモデル内で実装するべき。一番大切なテストはビジネスロジックであるわけだし、モデルに集約して
（かつコントローラとのｲﾝﾀﾌｪｰｽも疎結合にして）コアロジックを実装することでコアロジックを別システムに
再利用しやすくなるというメリットも受けられる。

なので、コントローラはある意味、テストをしなくても問題ないくらい「薄い」実装にするべきだし、コントローラ
内で繰り返しよく使う処理についてはコンポーネント化してあげたほうが、ユニットテストで品質を保証できるので
良いかと。

こんな感じで考えていますが、どうでしょう？

523:nobodyさん
08/04/02 16:44:10
>>519
Seleniumこれだけあれば、全く十分なんだが
これ以外でテストしようとすればコストかかるだけやろ
どんくさい作業してんな、赤字やろ？

524:nobodyさん
08/04/02 16:50:49
>>522
だから何ってかんじだが、それがどうしたんだよ
リファレンスに書いてあるようなこと、なんで必死に訴えてるのｗｗｗ

525:nobodyさん
08/04/02 16:52:59
自演厨きたー。うぜえええ

526:nobodyさん
08/04/02 16:56:38
Seleniumなんかでテストしたら時間（＝コスト）がかかるよ。
ブラウザを起動する為、そもそも動作が遅いってのもあるが、

Seleniumだといくつものモジュールが組み合わさった状態で
テストするしかないから、どこのバグがあるのか見つけにくい。

またデータの初期化などが出来ない。
途中で内部のデータを調べることも出来ない。

CakePHPにはSimpleTestでブラウザをエミュレートした状態の
テストもできるので基本はそれを使ったほうが良い。

Seleniumを使うとしたら、SimpleTestではできない
JavaScriptが絡んだ処理のテストぐらいだな。

527:nobodyさん
08/04/02 16:58:43
リファレンスに書いてあるようなことなのだから、
間違いではないということだなｗ

528:nobodyさん
08/04/02 17:01:36
>>522
アプリケーションの中心となるビジネスロジックて何？
どんなロジック？

一番大切なテストてどんなテスト？

>>モデルに集約して
（かつコントローラとのｲﾝﾀﾌｪｰｽも疎結合にして）コアロジックを実装

プラグインと違うの？

>>なので、コントローラはある意味、テストをしなくても問題ないくらい「薄い」実装にするべき

モデルとビューに命令出すのに薄い実装なんて物理的に無理
モデルはカラッポでＯＫ

529:nobodyさん
08/04/02 17:04:44
>>526
ブラウザ上でテストするだけなのにモジュールとか関係ないしｗｗｗ
JavaScriptテストやるなら加工しないと出来ないだろｗｗｗ

530:nobodyさん
08/04/02 17:05:56
>>526
Selenium使ったことないやろ？正直にいえ

531:nobodyさん
08/04/02 17:08:00
SimpleTestの方が時間かかるよ

532:nobodyさん
08/04/02 17:08:48
内部のデータを調べるようなテスト時間かかるに決まってるやろ

533:nobodyさん
08/04/02 17:09:00
また、例の嵐だな。

534:nobodyさん
08/04/02 17:09:39
とりあえず言っておくけど、CIは糞だから、
糞スレでやってねｗ

535:nobodyさん
08/04/02 17:13:49
>>532
たしかに！

536:nobodyさん
08/04/02 17:16:18
>>522
日本語でおｋ

537:nobodyさん
08/04/02 17:18:56
なんか、CI普及の為（？）にわざとアフォなことを言っている気がする。
いや、まて、わざと悪い例を出しているのか？

まあ、訂正している俺は考えをまとめられていいけどな。
（そして訂正している文を見て学習する人もいるだろう）

> モデルとビューに命令出すのに薄い実装なんて物理的に無理
> モデルはカラッポでＯＫ

コントローラが出す命令はすごく小さなものだよ。
モデルに対して、「データ取って来い！」「書き込め！」「削除しろ！」
そして、「複雑な一連の処理をしろ！」

前三つは、CakePHPの自動生成コードでも書いてあるから
簡単にわかると思うけど最後の「複雑な一連の処理をしろ！」を
モデルに書くべきってことをわかってない人が多いんだよね。
複雑な一連の処理をコントローラに書いてしまう。悪い例だ。

538:nobodyさん
08/04/02 17:27:44
>>537
テストのことを考えていってんの？俺はテストはブラウザでしかしないからｗ

539:nobodyさん
08/04/02 17:29:17
テスト中心に設計するならモデルに詰め込めるだけ詰め込めばいいんじゃね

540:nobodyさん
08/04/02 17:30:57
>>537
複雑な一連の処理を具体的に述べよ
はなしはそれからだ

541:nobodyさん
08/04/02 17:32:26
where が入るような条件文はモデルに書けばいいの？

542:nobodyさん
08/04/02 17:33:42
>>537
モデルにもっていっていいのは
どこからどこまで？

543:nobodyさん
08/04/02 17:45:27
>>537
いくら給料もらってんだよ
俺はＰＨＰプログラマで36万円

544:nobodyさん
08/04/02 17:53:38
　
　
　
モデル上で別のモデルのデータ取得できなくね？
　
　
　

545:nobodyさん
08/04/02 17:55:24
>>542
どこまでをモデルでやるかは結局設計しだいだけど、

>>541
ユーザーがフォームからの条件入力。URL形式での条件入力
、つまりコントローラのアクション関数の引数に入る場合。

その引数をもとにモデルを呼び出すわけだけど、
このときのモデルの関数は汎用的なfind関数でもいいし、
もっと簡単に扱いたければ、モデルに専用の関数を作って呼び出す。

汎用的なfind関数を使う場合には、array('key' => '= ' . $value)なんて
条件データに加工しないといけないよね？これがコントローラの処理。

モデルに専用の関数を作る場合、もっと簡単に使える関数にするね。
もちろんその場合、モデル内部でfind関数を使うことになるだろうし、
そのための条件の加工もモデルに書く。

ユーザーの入力した条件が、POSTでくる場合は、
$this->dataから条件を作り出す所までもうちょっと
コントローラでやる仕事が増えるだろう。

それでもコントローラの処理（モデルを呼び出すところまで）はこれだけ。
俺ならこのように作るよ。

あとモデルから戻ってきたデータを、ビューで使いやすいように
単純化するのもコントローラの仕事だね。

546:nobodyさん
08/04/02 17:59:00
>>544

> モデル上で別のモデルのデータ取得できなくね？

モデル上で別のモデルのデータを使用したいと思ったとき、
その二つのモデル間には関連性がある。

つまりアソシエーションを定義している。
アソシエーションを定義しているのなら、
モデル内で、別のモデルを呼び出すことが出来る。

Model1の中から、$this->Model2->findAll(); 感じで呼び出せる。

547:nobodyさん
08/04/02 18:01:31
>>545
モデルから戻ってきたデータを、ビューで使いやすいように単純化

数字にコンマ付けたりとか？

548:nobodyさん
08/04/02 18:02:43
>>546
そのやり方はCakePHPで推奨されてる方法なの？

549:nobodyさん
08/04/02 18:05:48
>>546
わざわざアソシエーションするの？
いつも結合されて重くなるじゃん

550:nobodyさん
08/04/02 18:06:46
>>547
それは見た目を変えるだけだからビューの仕事だろうね。

モデルから戻ってきたデータとは、汎用的なfind関数の場合、

$data => array(
　モデル名 => array(
　　フィールド名1 => 値1,
　　フィールド名2 => 値2,
　　フィールド名3 => 値3,
　)
)

こんな値が返ってくる。もちろん、これをそのまま
ビューに渡してもいいんだけど、これじゃあビューで使いにくい！
って言う場合加工する。

そんな場合あるのかって？余り無いだろう。
そう、だからコントローラの仕事は少ない。

モデルから取得した値をビューに渡す$this->set(・・・) は
コントローラの仕事ね。

551:nobodyさん
08/04/02 18:07:42
>>549
必要なときにつけたりはずしたりする方法は、何度も既出

552:nobodyさん
08/04/02 18:11:37
>>548

だめなのか？

553:nobodyさん
08/04/02 18:12:12
>>546
なんでモデルでやるの？そのメリットは？

554:nobodyさん
08/04/02 18:21:49
>>553
もちろん、直接関係が無いモデルは別々に
アクセスするよ。

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

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

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

555:nobodyさん
08/04/02 18:23:17
>>546
モデルは複雑にすべきじゃないよ。な中規模設計したとき
アソシエーションで必ず問題起きそう

556:nobodyさん
08/04/02 18:27:56
>>555
その意見はわからないでもないが、

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

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

557:nobodyさん
08/04/02 18:28:26
×RDBMSを正規化したとき
○RDBMSでテーブルを正規化したとき

558:nobodyさん
08/04/02 18:32:44
>>546
ページ数が増えたとき、コントローラを増やすことができるけど
コントローラが増えた分モデルを増やすこと出来ないよ。
ひとつのモデルに書くコードが恐ろしく増えるね

559:nobodyさん
08/04/02 18:34:17
また例の馬鹿か？

560:nobodyさん
08/04/02 18:35:56
> コントローラが増えた分モデルを増やすこと出来ないよ。

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

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

561:nobodyさん
08/04/02 18:43:36
全てはコントローラに処理を詰め込み過ぎたscaffoldが悪い。
あれがアフォに勘違いを植え込む。

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

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

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

563:nobodyさん
08/04/02 18:53:30 KzinrGTW
debugを1以上にするとHTMLの一番最後に

みたいに、生成時間？のコメントがつくんですけど
これを付けないようにするにはどうすれば良いんでしょうか？
debugは1にしておきたいです。

564:563
08/04/02 18:58:51
あ、webroot/index.php にありました。

565:nobodyさん
08/04/02 19:00:37
cakephpで作られたオープンソースみても
モデルで書かれてる処理はバリデータ関係の関数しかないんだけど

URLﾘﾝｸ(code.google.com)

566:nobodyさん
08/04/02 19:00:38
>>564
Do not changeって書いてあるけどねｗ

567:516,522
08/04/02 19:01:23 Ldo05SB7
ん？なんかいろいろゴチャゴチャしてきたけど、結局俺が主張してたことは正しかったのか・

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

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

568:nobodyさん
08/04/02 19:06:54
>>565
お前の目は節穴か・・・

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

569:nobodyさん
08/04/02 19:08:08
OpenFLP
Rails 製のオープンソース版 Fastladder

モデル　382steps
コントローラー 910stepｓ

コントローラーに処理書きまくってるんですが。。。

570:nobodyさん
08/04/02 19:09:00
じゃあ本家railsのソースコードみせてやる

571:nobodyさん
08/04/02 19:11:13
コントローラに処理を詰め込みが正論か非か
オープンソース見れば、すぐわかることだからな

572:nobodyさん
08/04/02 19:15:29
オープンソースといってもその質はピンキリだから

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

573:nobodyさん
08/04/02 19:18:52
>>567
全部コントローラで出来るし
それをCakePHPでやる意味がわからんｗ

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

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

575:nobodyさん
08/04/02 19:58:32
>>574
CakePHPでやることじゃないことは確かｗｗｗ

576:nobodyさん
08/04/02 21:14:45
ビジネスロジックはモデルに集約すべき
議論としては面白い
俺もその辺気になってた

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

577:nobodyさん
08/04/02 21:37:43
>>576
俺もコントローラに書いてしまったけど、
作り続けていくうちに、なんか無理が出てくるんだよ。

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

578:nobodyさん
08/04/02 21:58:22
>>577
その絵ってどれ？

579:nobodyさん
08/04/02 21:58:46
>>562
モデルに書けって言うけど、何を書くの?
関数で書けばいいの?モデル内のメソッドとして?

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

580:nobodyさん
08/04/02 22:16:06
>>578
これの3ページ目
URLﾘﾝｸ(cakephp.org)

581:nobodyさん
08/04/02 22:19:41
> 関数で書けばいいの?モデル内のメソッドとして?

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

582:nobodyさん
08/04/02 22:22:03
>>580
ありがとう，でもコントローラーよりモデルに重点おけよという一言で済む話かｗ

583:nobodyさん
08/04/02 22:26:19
>>581
そうすると、どう幸せになれるわけ?

584:nobodyさん
08/04/02 22:27:49
>>583
どう幸せになるかではなく、
どう幸せになりたいか。

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

585:nobodyさん
08/04/02 22:57:59
railsはコントローラーに重点を置くようになってるのではなぜ？

586:nobodyさん
08/04/02 23:14:04
>>574
自分の安価間違ってね？516と522で筋が通ってない

587:nobodyさん
08/04/02 23:53:19
>>585
railsでもモデルが一番重要なものですよ。

588:nobodyさん
08/04/03 00:17:09
モデルが一番重要なんてCakePHPだけの話
松本に話したら鼻で笑われたよ

589:nobodyさん
08/04/03 00:38:13
松本といっても鼻の長いゾウをキャラクターにしている会社の松本だけどなｗ

590:nobodyさん
08/04/03 00:48:42
でもキリンさんも好きなんだろ？

591:nobodyさん
08/04/03 10:10:52 Z1Ohe4yI
ビヘイバ話はおわったのか？

592:nobodyさん
08/04/03 11:26:08
Model は特定の環境に依存しない処理を行う部分である。

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

594:nobodyさん
08/04/03 12:26:23
ビヘイビアて1.2からだろ、
最初から無いってことは必要性が薄いてことだよな

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

596:nobodyさん
08/04/03 12:32:23
画像アップロードできるビヘイビアあるよ。
正確には画像を保存できるビヘイビアだけどね
URLﾘﾝｸ(bakery.cakephp.org)

597:nobodyさん
08/04/03 12:50:28
結局はソースを見やすくする為にある。
一番見やすいソースとは、なるべく何も書かないこと。

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

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

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

598:593
08/04/03 13:32:44
>>596-597
ありがとうございます。
こりゃ1.2にチャレンジしなきゃだな

599:nobodyさん
08/04/03 13:49:15 Z1Ohe4yI
>ビヘイビアて1.2からだろ、
>最初から無いってことは必要性が薄いてことだよな

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

600:nobodyさん
08/04/03 14:22:02
railsにはビヘイビア相当になるものが無いんだが、どうして

601:nobodyさん
08/04/03 15:14:18
ビヘイビアてベネズエラにいる俺の愛人と同じ名前だ

602:nobodyさん
08/04/03 15:38:42
>>600
Rubyではmixinという言語機能でビヘイビア相当のことが出来るから。

603:nobodyさん
08/04/03 17:41:48
マニュアル»CakePHPによる開発»Models»Introduction
URLﾘﾝｸ(book.cakephp.org)

> Model behaviors provide a way to mix in functionality

へぇ、behaviorsはmix-in的な機能を提供するものだったんだ。なるほど。

604:nobodyさん
08/04/03 18:10:28
>>603
きちんとした日本語訳サイトあるのに。。。

605:nobodyさん
08/04/03 18:23:11
>>604
どこに？

606:nobodyさん
08/04/04 20:03:22 GG6uDHIa
わっふるわっふる

607:nobodyさん
08/04/05 04:54:50
cakeでのMC棲み分け例としては以下がありますよね。
個人的にはいい感じだと思いましたが、どうでしょう？

CakePHPを使ったMVC設計のベストプラクティス
URLﾘﾝｸ(www.sooey.com)

608:nobodyさん
08/04/05 05:21:49
MVCモデルのＭが重要なのはデータ加工の多いＷＥＢだけのはなしであって
ＭＶＣモデル全般的な考えではない

609:nobodyさん
08/04/05 05:24:58
データをあまり使う必要のないＷＩＮアプリを
ＭＶＣモデルでわけた場合はＣが中心となる

610:nobodyさん
08/04/05 09:45:41
Web用のフレームワークのスレで何言ってんだこいつｗ

611:nobodyさん
08/04/05 15:00:48
ＭＶＣのＶが重点となるソフトをあげてみよ

612:nobodyさん
08/04/05 15:07:51
rails発のＭＶＣモデルはＭがＤＢと密接な関係であるが
最強のモデルとは思っていない。
最適なモデル構造というには、まだまだ完成度が低いとrails作者は言っている

613:nobodyさん
08/04/05 15:49:00
>>607
面白いけど
これ通りに書いたら一覧性下がりそうだな
大規模なら修正には強くなりそうだね

まずは体に叩き込んでみるのがいいのか

614:nobodyさん
08/04/05 20:57:16
>>611
> ＭＶＣのＶが重点となるソフトをあげてみよ

静的なウェブページ

615:nobodyさん
08/04/07 17:32:08
ゆくゆくはcake使いたいけどあと8時間くらいしか時間ないし
今は勉強してる暇も無いからとりあえず平で書く
ってときに、最低限これだけ守ってコード書いとけば
あとでcakephpを使いたくなってもまあなんとかなるよという
ポイントを教えて

616:nobodyさん
08/04/07 17:50:23
Cake同様のライブラリが揃ってるってなら、そんな事も可能だと思うが・・。
無理じゃね

617:nobodyさん
08/04/07 18:06:48
データベースの主キーはIDだけにしておく

618:nobodyさん
08/04/07 18:28:13
それはコードなんだろうか
とにかく規約ぐらい把握しないと無理だよね
結局出来るのはDBの設計ぐらいじゃないかと

コードも処理部分は多少使いまわせるだろうけど

619:nobodyさん
08/04/09 22:36:27 0zi6cM/k
CakePHP内でfindAll、findAllByを使っていますが、重いのでチューニングできないかと
考えています。

それで、実際に発行されているSQLと、可能であればアクセスパスを確認したいの
ですが、なにか方法がありますでしょうか。

620:nobodyさん
08/04/09 23:44:43
デバッグモードを2に変更。実行したsqlが見れます

621:619
08/04/10 00:04:23 ysAxvq3P
>>620
確認できました！ありがとうございます。

622:nobodyさん
08/04/10 10:23:53
Model->query()で以下のようなSQLを発行すると
$sql = <<<EOF
　　SELECT
　　　　`Foo`.`id`,
　　　　SUM(`Bar`.`hoge`)
　　FROM `bars` AS `Bar`
　　LEFT JOIN `foos` AS `Foo` ON (`Bar`.`foo_id` = `Foo`.`id`)
　　WHERE `Foo`.`id` IN (1, 2, 3, 4, 5)
　　GROUP BY `Foo`.`id`
EOF;

連想配列の添字がおかしくなるのですが、回避はできないのでしょうか

array(
　　'0' => array(
　　　　'Foo' => array('id' => ***)
　　　　'0' => array('SUM(`Bar`.`hoge`)' => ***)　←ここ
　　)
　　.
　　.
　　.
)

623:nobodyさん
08/04/10 10:42:01
>>622
なんかqueryなんか使わないで、find()で出来そうな気がするんだが？
queryだとRDBMSごとの違いを吸収できないことがあるのでお勧めしない。

んで、試してないんで間違っている可能性が高いんだが
$sql = <<<EOF
　　SELECT
　　　　`Foo`.`id`,
　　　　SUM(`Bar`.`hoge`) as `Bar`.`hoge`
以下同じ

じゃだめかな？

内部的には帰ってくるデータのフィールド名がどうなっているかを判断して
連想配列に入れているようだから、SUM関数とか使うとフィールド名が
CakePHP的に想定外になる。それが原因じゃないかな？

ちなみに、この、 as `Bar`.`hoge`の文字列の部分がRDBMSによって違うので
考えなしに使ってしまうと、RDBMSごとの違いを吸収できなくなる。
（たしかPostgreSQLだとas Model__Field）
もちろん、MySQLにだけ対応していればいいのなら、問題ないけどね。

624:nobodyさん
08/04/10 11:29:33
>>623
レスありがとうございます
alias噛ませる方法は私も試してみたのですが
FROM `bars` AS `Bar`の宣言と被っているためエラーが返ってきます。

hasManyで繋がっている集計先テーブルの条件指定なども追加したい場合
CakePHPの作法だとどのようにするべきなのでしょうか？

625:nobodyさん
08/04/10 11:53:32 BE:39571564-2BP(2)
参照の参照がうまくいかない。
たとえば、PostのViewにユーザ名だけでなく、そのユーザが所属するグループ名を表示したい場合、どうすればいいんだろう？
Post.id
Post.user_id－参照→User.id
　　　　　　←取得－User.username
　　　　　　　　　　User.group_id－参照→Group.id
　　　　　　←取得－－－－－－－－－－－ Group.groupname

User.usernameを表示する場合は、$post['User']['username']でいけるっぽいけど、
じゃあ、そのユーザのグループ名はどうやって取得すればいいんだろう？

他にも、グループ名のリンクをクリックしたときに、そのグループに所属するユーザ
（User.group_idの値がGroup.idの値と等しいユーザ）User.usernameの一覧を作成するときとか
どのように書けば良いんだろうか？

MVCにしろ、SQLにしろ始めたばっかで全然わからないや。

626:nobodyさん
08/04/10 15:04:31
>>625
Post -> User -> Group　という順番に適切なアソシエーションが設定されていれば、芋づる式にデータは取ってこれる。

やってるけど分からないなら>>620が書いているように、デバッグモードをonにしたほうがいい。

その質問の仕方だと、何をどこまでやって分からないのか分からない。

627:nobodyさん
08/04/10 22:22:07
>>624
とりあえず、
SUM(`Bar`.`hoge`) as `sumhoge`
これだと、
Array([0] => Array([0] => Array([sumhoge] => 6)))
となるよ。

まとめて書くなら、
$query = array(
'conditions'=>array(
'Foo.id'=>array(1,2,3,4,5),
'1=1 GROUP BY Foo.id'
),
'fields'=>array('Foo.id','SUM(Bar.hoge) as sumhoge')
)

$this->Bar->find('all',$query);

って感じかな

628:nobodyさん
08/04/10 22:25:44
まあ、SUMつかったせいで、
どこのモデルのデータかという情報が消えてしまい、
0という名前のモデル名になるってだけで
おかしいわけじゃないんだけどな。

今回はBar.hogeのSUMだからモデル名はBarになるべきだと
思うかもしれないけど、SUM(`Foo`.`hoge` + `Bar`.`hoge`) という
書き方だって出来るわけだし。

次ページ