元スレ【PHP】フレームワーク CakePHP　5ホール目【v1.2】

php覧 / PC版 /

みんなの評価 : ☆

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

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

351 = :

>>347

次なに使うの？

352 = :

>>349
別人？なにを言ってるんだ
おまえは誰か特定の相手に話しかけてるのか？こんな場所で？

俺は今回の話題ではCakeはバグ大杉使えないFW派だよ

353 = :

まぁこれからCake使うやつに助言

規約からはずれたことはするな
でも、それじゃあ大した物は作れない

組み込みのライブラリは使うな
全部自分で一から書け

FW使う意味ねーｗ
まぁぱっとみ使いやすいとは思うんだけどね
ここまでバグ多いとな…

355 = :

ちなみにCakeはオブジェクト指向じゃないって話あったけど
問題なのはAPIじゃなくてコアのコード内部なんだよね
ハックするのも一苦労

あのスパゲッティな有様じゃCakeの将来は危ういよ

356 = :

というかPHPのFWはまともなのがないな

Yiiとかってどうよ

357 = :

>>354
レンタルサーバで動かす気ない人か

358 = :

PHPでオブジェクト指向ってもっさりフレームワークの登竜門だろｗ

359 = :

Cakeは既にあらゆるフレームワークの中で最も重い部類

360 = :

で、なんかいいのないのか？

兄弟とか言われてるCIは、命名規則に統一性が乏しいし

361 = :

>>359

363 = :

PHPのユーザ層が重視するのは簡単に導入できる事と
HOWTO情報の多さだからでしょ
使ってる人たちはCakeしか使ったことないんじゃないの

364 = :

PHPったって殆どの人は楽天やGREEを作る訳じゃないんだから
重さって気にする意味無いよね
重さで言えばRoRとか死ぬほど重いんだし

365 = :

重いのは誰も問題にしてないけどね

367 = :

ところで、セッションってモデルだと思うんだが、
なんで、モデルで使えないのかね

371 = :

>>368

そうか？
データのやりとりするんだから、モデルだと思うけど？
まあ場合にもよるだろうけど

373 = :

なんでこんな使いにくくてバギーなcakephpが人気あるんかね？
たしかに、とっつきやすさはsymfonyやzendよりも上だと思うが
それだけなんだよね。
PHP使ってるやつはプログラム自体初心者が多いんだろね。
チュートリアル作って終わりなやつが多いんじゃね？

374 = :

玄人の言語で作れば？

375 = :

確かにPHPを使う意味なんてないんだよね
フレームワークを使うほどの開発になった時点で

377 = :

>>375
いいこというね～
PHPが最高に輝く使い方だね。

378 = :

好きな言語すら入れられない環境の方がかなりマイナーだと思うよ
個人だろうと企業だろうと普通はその程度の自由度はある環境でやってるよ

380 = :

セキュリティ面のバグの多さからWWWに出す時点でCakeは良くない

383 = :

RoRを覚えるのが面倒というのもあるな
Ruby動かせないときもあるしなあ

384 = :

>>382
実際作ってみると業務システムのパターンは極めて限られていることがわかるよね。

385 = :

そうでもないけどな
データ登録以上にワークフローと帳票が多い

386 = :

ワークフローと帳票といっても
結局はCRUDだしなぁ。

387 = :

可哀想な人が来たな

388 = :

>>387
その人、いらっしゃ～いｗ

389 = :

パターンは極めて限られていると見積もったCRUDシステムを
作るたびに炎上させる優秀な技術者様達

390 = :

1つのテーブルにいろいろな画面(コントローラ)からアクセスする場合、
モデルは、テーブルと対になるようにして1つのモデルにするのがよいか、
それともコントローラと対にするか、どちらが一般的でしょうか？

例えば受注テーブルがあり、
あるコントローラでは受注数を表示するのがメインの処理で、
また別のコントローラでは受注金額を表示するのがメインの処理、
のような場合、受注テーブルのモデルを1つ作成するのか、それとも
コントローラ毎に作るのか…。

391 = :

おまえはＭＶＣの基本についてすべて一つ一つｔ質問するつもりか

392 = :

>>390
無論、モデルはひとつ。

393 = :

>>390
コントローラーってのは要するに人がプログラムにアクセスする時のURLなわけよ。
だから人から見てわかりやすけりゃ良いわけで、モデルと対になってる必要なんて無い。
ってのが俺の考え。
逆に同じテーブルにモデルがいくつもあったらプログラム作る時に混乱するんじゃない？
それぞれ特殊なfindメソッドでも作ってるんなら別だけど。

395 = :

やっぱりモデルは1つにまとめるべきなんですね。

今回質問したのは、>>393 の
「それぞれ特殊なfindメソッドでも作ってるんなら別だけど。」
がまさしくそれで、取得対象のテーブルは1つなんですけど、
そのデータの取得方法や見せ方が全然違って、ただ当然コントローラは
個別に存在するので、
1つのテーブルを元にその見せ方毎にモデルを作りモデルの中で、
var $name = 'table'; としておきつつ、
それぞれの取得するためのメソッドを作成していこうかな、と思い作りはじ
めた矢先、取得テーブルは1つなので、そのモデルに全部メソッドをまとめた
ほうがいいのか？と迷いはじめてしまい…。

テーブル単位にメソッドをまとめるのか、機能毎にモデルを分割するのか…。

まだまだ精進がたりませんね、大変すみませんでした。

396 = :

>>394
http://d.hatena.ne.jp/charly24/20070512/1178956046

398 = :

>>395
>テーブル単位にメソッドをまとめるのか、機能毎にモデルを分割するのか

一律的な分け方をすると後で縛りがきつくなるから
機能目的によってバランスよく分別した方がよい

399 = :

むしろ厳密に言えば両方違う
２モデルを１つのテーブルに格納することが可能だから

400 = :

テーブルやモデルの対に関して議論することがアホらしいｗ
後退的議論で無意味