>>199
オブジェクトで呼んだ方がオーバーライドもできるし
後から制御するのが楽

柔軟な制御をするためにデータはオブジェクト経由で呼ぶべき
オブジェクトで呼ぶことに意味がある
それは、オブジェクトにはいってるデータを
外から制御できるからだ

>>201
>>202

cakephp やってて

「意味あるのかな・・・」と思ってましたけど、やっぱり意味があったんですね。

勉強になります。ありがとうございます。

例えばCakePHPでブログシステムを作るとして、
ユーザ（usersテーブル）、投稿（commentsテーブル）が一対多の
関係にある時、あるviewで、
　ユーザ1
　　コメント1-1
　　コメント1-2
　　コメント1-3
　ユーザ2
　　コメント2-1
　　コメント2-2
　　コメント2-3
　　　・
　　　・

という表示をさせたいのですが、view、controllerをどう書いてよいか悩んでいます。
modelで、hasManyリレーションを貼るところ迄は合っていますか？

どこか、参考になるページがあれば教えて下さい。

表示するユーザ数+1のクエリが発行されるからアクセス数の多い中規模～大規模なサービスでは使えない。
この辺言及する人が少ないのはcakeユーザのレベルが低いからだろうか。

> 表示するユーザ数+1のクエリが発行されるから
何を言っているんだ？

自分のレベルが低いと告白しているのか？

>>206
だって、表示するユーザ数+1のクエリが発行されないから。
誰も指摘しないのは当たり前。

>>207
>>208
お前らのcakeはこの時どういったクエリが発行されんの？

select ... from users ... (id 1,3,5のユーザがヒットする)
select ... from comments where user_id in (1) ...
select ... from comments where user_id in (3) ...
select ... from comments where user_id in (5) ...

http://72.14.235.104/search?q=cache:frA0R04esqgJ:ameblo.jp/lamp777/entry-10072229261.html+cakephp+%E3%82%A2%E3%82%BD%E3%82%B7%E3%82%A8%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3+left+join&hl=ja&ct=clnk&cd=10&gl=jp

そして、この findAll() で実行された SQL は以下の通り。

SELECT `Job`.`id`, `Job`.`com_id`, `Job`.`name`
FROM `jobs` AS `Job` LEFT JOIN `coms` AS `Com` ON `Job`.`com_id` = `Com`.`id`
WHERE 1 = 1 ORDER BY `Job`.`id` ASC LIMIT 10;

子はJOINできないじゃん。
結局「表示するユーザ数+1のクエリが発行される」が間違ってることは示せないんでしょ。
実際やってみてクエリログ見ればすぐ分かるはずなんだが。

>>210
素人乙！
観点がずれてるよＰＨＰの基礎からやりなおしてね

１回のクエリで全てが補えることに超したことはない
その代わり複雑なＳＱＬ文を書かないといけないから
CakePHPの負荷よりも生産性というスタイルに合わないがな
ループの中でクエリをぐるぐる発行しまくると負荷が高くなる

>>215
結局こういうのが出てくるのか・・・
ほんとバカばっかだなー

それじゃ論点がどうずれてるか説明もらってもいい？
210での発言にphpの基礎は全く関係ないから、それのほうが論点ずれてると思うのだが。
んで、実際お前のcakeではこの処理でどういうクエリが発行されんの？

>>209
よほどのことがない限り
ループの中にループは入れない方がいいよ
負荷がかかるからね。

CakePHPのおかげで
とてつもなく負荷の高いシステムがたくさん世に出そうだな
こりゃサーバー会社が儲かるな
sakuraインターネット株でも買うか！

1.2のpaginate機能はつかえねーな
柔軟な制御ができん、
ページリンクに検索項目のパラメーター付加できない、というか
できるけど、面倒なことしないとダメくさい
ソート項目のパラメータは標準で付加できるようだが

>>218

私の技術力だと、二重ループ以外に実現する方法が思いつかないのですが、
他によい方法があったら教えてもらえますか？

ユーザ毎のコメントを表示する機能はパスするにしても、
同様にmasManyリレーションのテーブルを親子両方とも表示したい
機会はあると思うので。


負荷という意味では、masManyの定義でlimit=>10とする事で大量の子を
取得しないように、というのは心がけています。

>>219
もっと負荷の高いsymfonyもありますぜｗ

というか、プライマリーキーで
データを取得することが
負荷が高いと思っているのかな？

JOINの方がよっぽど負荷高いですぜ。

DB周りじゃないだろ多分

>>210
> お前らのcakeはこの時どういったクエリが発行されんの？

こういうクエリが発行されますがなにか？

select ... from users ... (id 1,3,5のユーザがヒットする)
select ... from comments where user_id in (1, 3, 5 ) ...

CakePHPのどんどん負荷をかけて生産性を上げなさいというスタイルが
自分の性格に合わない気がしてきた

まだ、例のアンチが常駐しているのかｗ

CakePHPはメモリも食わないし、負荷も高くない。
生産性は高い。

アンケート

1.ページ送りの絞り込み条件パラメータをセッションで持たせている
2.ページ送りの絞り込み条件パラメータをURLの後ろに繋げてる(CakePHP1.1 paginate)
3.ページ送りの絞り込み条件パラメータをURLの後ろに繋げてる(CakePHP1.2 pagination)

>>227
矛盾してるな。それらは反比例の関係にあるからな

>>226
たしかに、
●自分の用途に合わせて、全てのコードとHTMLを一から作成したシステム
●作り込み部分は最小限にして、大半のコードはcakePHP任せにしたシステム
を比べると、負荷は、一から作成したシステムの方が、余分なものがない分、
軽くできるかもね。

まあそこはトレードオフの部分だから、自分に向いてないと思ったら、
cakePHP以外のやり方を模索すればいいと思うよ。

>>230
よくわからんが、いまどき生産性の悪いほうを
選びたいのか？

負荷が高いシステムを作っているところは
どこでもフレームワークを使っている。

>>233
どちらかと言うと、「負荷が高いシステム」と言うより、
「大規模なシステム」はフレームワークを使ってるという感じじゃない？

そうしないと、コーディングや保守が大変だもんなあ。

結局は、昔からある速度重視でアセンブラ（生PHP）で書くか、
生産性重視で高級言語（フレームワーク）で書くかの話でしかないな

小規模フレームワークはＣＩが一番だと思うんだよね
CakePHPは小規模フレームワークのクセにsymfonyと同レベルくらい負荷かかりすぎ

>>238
宿題。

それをデータで示してください。

つーか、何をもって小規模といっているのかわからん。

機能が少ないほうが早い。 機能と速度どっちをとるかだ。

>>239
10万stepまで　小規模
データは「CakePHP CodeIgniter ベンチマーク」でググれ

>>239
http://www.tsujita.jp/blojsom/blog/default/PHP/2007/07/13/PHP%E3%83%99%E3%83%B3%E3%83%81%E3%83%9E%E3%83%BC%E3%82%AF-Zend-Framework-vs-Symfony-vs-CakePHP-vs-CodeIgniter-vs-PHP-on-TRAX.html

だめだな。CodeIgniter は小規模でしか使えない。
一番重要なモデルが貧弱すぎる。中規模以上ならCakePHPだな。
http://blogs.atanaka.biz/tanaka/index.php?itemid=691

・フレームワークにありがちな、あまり使わない機能が削がれている
・フレームワークにありがちな、よく使う機能もけっこう削がれている。
・だから、ステップ数が他のPHPフレームワークと比べて格段に少ない。
・だから、実行速度が速い。（ベンチマークはこちら）
・フレームワーク自体が複雑なことをしようとしていないので、潜在バグの深刻さも小さい。（たぶん）
・マニュアルがかなり読みやすく、取っつきやすい。
・cakePHPには名前のインパクトには負ける。
・ZendFramework には格式の高さで負ける。
・MVCというよりは、VCだ。モデルはあくまでもおまけ的。
・PHPがそもそもテンプレート的なんだからテンプレートエンジンいらない、と考えているふしあり。（だから速い、と）
・でも、簡単な変数置き換えの簡易テンプレートはデフォルトでついてるし、Smartyとの連携もできる。

>>243
モデルはCIベースでオレオレ的に拡張した方がいい。
CakePHPの既存モデルにしっくり来ないから
まずコードが凄く見難い状態になる
結局バリデートにYAML使ったりと拡張しないいけない

小規模　CI
中規模 CI
大規模　ここまできたらCIでいいや

ＣＩのサクサク感を味わうと他のＦＷは使えない

>>225
それバージョンいくつ？

viewの先頭でoptions()を使って追加文字列をセットしておけば、prev()やsort()等で追加の指定する必要なくなる
$paginator->options(array('url'=>'hogehoge'))

controllerでpaginate(モデル)した後のoptionsにセットしてもurlに展開される
$this->params['paging'][モデル]['options']['hogeoge_key']='hogeoge_value'
*この方法は裏技的な気がするけど、、、