コンテンツ

ホーム価格広場掲示板ゐ記ツール書庫統計情報

牧場内検索

カウンタ

総計:	127,646,780人
頁
昨日:	no data人
頁
今日:	人
頁

元スレ【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で

201 = :

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

202 = :

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

203 = :

>>201
>>202

cakephp やってて

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

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

206 = :

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

207 = :

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

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

214 = :

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

215 = :

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

216 = :

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

217 = :

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

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

218 = :

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

219 = :

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

221 :

>>218

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

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

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

223 = :

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

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

224 = :

DB周りじゃないだろ多分

226 = :

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

227 = :

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

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

230 = :

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

231 = :

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

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

232 = :

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

233 = :

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

236 = :

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

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

237 = :

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

239 = :

>>238
宿題。

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

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

240 = :

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

243 = :

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

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

245 = :

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

248 = :

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

249 = :

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