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

252 = :

痛いCI厨は自分のスレを盛り上げてこいよｗ
わざわざCakePHPスレを盛り上げて乙

253 = :

経験から言うと、どんなものでも「軽い！」という触れ込みでデビューしたものは、
最初は機能が少なくて、バージョンがあがるにつれて機能が追加され最終的には重くなるんだよな。
で、ほかと同等の機能を備えたときには、ほかと同等の重さになっている。

258 = :

>>256
>>257
面倒ならカスタムsqlでやれば早いじゃん

259 = :

んー、Commentに対するlimitがある場合はそう実装するしかないのか。
バカじゃん俺。この振る舞いについてのドキュメントはどっかにあったのかな。
連投スマソ。

261 = :

>>260
スレ違いだと思うんだけど・・・

263 = :

ぺルパーについてkwsk

266 = :

>>265
> コントローラにはあまり詳細な処理は書きたくない
> 具体的な処理はコンポーネントをこさえて、そちらで処理したい

大事なのはこれらの明確な理由が何なのかってことだと思う。
その会員登録処理がシステムの他の部分からも必要になるならコンポーネントにした方がいいと思うよ。
もしくは他のアプリでも(ほぼ)そのまま使用できるなら。
あとはコントローラとモデル(DAO層)を分離することでテスタビリティを向上させたいとかかなぁ
例えばテストの時はモックコンポーネント使うようにすればデータベースがなくてもコントローラのテストができる。

267 = 265 :

>>266
なるほど。コンポーネントで会員登録処理と思いついた理由は指摘のとおり他のアプリで
いつも同様のことを実装してるのでコンポーネント化してしまおうというのが一番の理由。
それにコントローラ内に細かい条件分岐や処理を書き始めるとものすごくコードが肥大して
メンテナンスがし難いし、もし今後会員登録のフローを同アプリケーションの別箇所でも使い
たいって仕様変更があっても対応しやすいかと。

でも、「会員登録（管理）コンポーネント」なんて作っちゃうとモデルやDBテーブルの構造が
かなり固定化＆依存してしまうのがいやだなだ、と…（AuthComponentみたいにね）
それならばpluginにしちゃえば？って考えることもあるけど、pluginってあんまり使われてないし。
うーむ。

268 = :

>>267
そんな恐ろしいほどにコードが肥大する。かつそれら共通利用する機会が多いなら
コンポーネント化しちゃいなよ

269 = :

>>267
DBテーブルの構造がかなり固定化＆依存

これ内容が会員登録だったらテーブル構造に依存しちゃうのやばいだろ？
会員認証なら固定依存しても、それほど問題ないけど
コンポーネントてそもそもDBテーブルの構造がかなり固定化＆依存してしまうものなんだね

270 = :

>>267
コンポーネント設計のポイントは、Plug-and-Playを可能にすることであり、独立性を高めることにある
重要となる設計要素は、インターフェースであり、注目すべきは設計要素間の依存関係だと思う
内部実装に依存しない形でコラボレーションをモデル化できるインターフェースが重要じゃないかな

コンポーネント化するということは、結局クラスをグループ化することだからね
クラス間の関連（集合-部分、汎化-特化）と依存関係を意識して設計しないと
物理的にはコンポーネント化したが、論理的にはひとつのシステム全体
ひとつの再利用単位として使わざるを得ないという状況が現れるから
この点で、依存関係の設計はかなり重要

271 = :

>>266
モックコンポーネント

あまり聞かない、組み合わせだけどｗ
モックとコンポーネント入れ替えするものじゃないの？

272 = :

モックンがどうかしたって？

274 = :

>>271
そういうこと。テストの時はモックを使うようにする。
「コンポーネントのモック」って意味でモックコンポーネントって言った。

275 = :

>>273
会員登録プラグイン

何度も使うような処理でも無いし面倒な処理でもないからなあ

個人的には確認画面やらページ送りやら何度も使う場面のあるプラグインもしくは
コンポーネントが欲しい

277 = :

>>276
おつかれっす

279 = :

>>278
ファンクションて何ですか？素人は書き込まないで下さい

281 = :

>>280
こんなとこで聞くよりも自分でソース見た方が早くね？

282 :

>>275
会員登録プラグイン、完成したら俺にくれ

283 = :

>>282
いらねー。たぶん需要ない
会員登録なんてすぐ作れるやんｗｗｗ

285 = :

いらなきゃ使わなきゃいいじゃん。
小さい車輪だろうが再開発をしなくて済むなら助かる。

286 = :

再開発する機会が少ない。激しく無駄
そうじゃなければ、すでに作ってる人たくさんいるよ

288 :

Cakeのプラグインって、なにか有名なのってあったっけ
なんのためにプラ銀機能なんて実装されてんの？

291 = :

ヘルパーは細かく考えずにコントローラ単位で呼び出すのがCake流
コンポーネントやモデルはヘルパーに比べればメソッド単位で呼び出しやすいけど
こっちも深く考えずにコントローラ単位で呼び出すんだ
多分

293 = :

まあ、そんなに特定のアクションでだけ
ヘルパーとか呼び出したいのなら、
そういうコンポーネントを作ればいいんじゃないのかな？

コンストラクタあたりで、url見てごにゃごちゃすれば出来るでしょう？

296 :

モデルってあんまりごちゃごちゃ書きたくないよな、dbdesigner2cakeとか使ってるとメンテナンスの面からとく。
だからといってコントローラにごちゃごちゃとロジックを書き並べたくないので
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます。

これって俺だけ？

297 = :

だからコントローラにいろいろ書くのは
まずいケーキだってケーキ様が言っている。

http://cakephp.org/files/OCPHP.pdf

298 = :

>>297
ケーキがどうのこうのいおうが
自分の見やすい書き方が一番

たとえば１万step以下のコードなら
全部コントローラに書いた方がいい、みたいなね！

299 = 296 :

>>297　
3ページ目？　こんなにモデルに書くもんかね…
俺だったらｃとｍの間のコンポーネントをずっしり書くな。別のプロジェクトにも使いまわしできるし。
コントローラだとほぼ、使いまわせないしな。

300 = :

1万ステップコントローラにべた書きとかすごいね