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

301 = :

>>296
コントローラに関する再利用性の高いメソッドはコンポーネント
モデルに関する再利用性の高いメソッドはビヘイビア

再利用性が高いロジックじゃないとダメ
そのロジックがコントローラ側かモデル側かどっちに属するかを間違えるとダメ

302 = :

>>300
再利用性が無いなら
１０万stepsでもコントローラにベタ書きするしかないよ

303 = :

>>299
コンポーネントはコントローラとモデルの仲介役じゃねーよｗｗｗ

304 = :

>>299みたいに再利用性の低いものまでコンポーネントはダメだろな

305 = 296 :

ビヘイビヤって1.2からのやつだよね？

306 = :

>>296
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます

これダメだろ？再利用性の高さとか無視してるやん

308 = :

都道府県データとか
男性・女性・オカマとか
こういうセレクトに必要な初期データはどこへ入れるの？

310 = :

>>309
モデルのメソッドの中に都道府県データをいれて
呼び出してもＯＫ？
もしくはＤＢからひっぱる、それ以外に方法はわからない

313 = :

>>298
ケーキを使っている以上ケーキ様の言うことは絶対です。

コンポーネントにいろいろ書くとどれだけテストが大変になるか。

314 = :

>>308
> 男性・女性・オカマとか
これじゃ足りないな。

現在の肉体的性別男・女
生まれたときの肉体的性別男・女

現在の精神的性別男・女
生まれたときの精神的性別男・女

好きな性別男・女・両方・肉体が男・肉体が女

まだ足りないかもな！

315 = :

>>313
再利用できないものは
コントローラーにいろいろ書くしかない
ケーク様が何も用意してくれてないから

318 = :

うんこちんちん

319 = :

こんなに、解釈によって作り方が変わって来ちゃうなら、フレームワークの「良い意味での縛り」のメリットが無いね。
それぞれが間違いとも正解とも言えないから余計めんどくさい。
もっと縛りがキツければ良いのに。

320 = :

>>319
バカがルールを勘違いしてるだけｗｗｗ

322 = :

俺が作っているやつでは、「自動入力フィールド」をビヘイビアでやっている。
ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。
データベースのセオリーからいえば計算で求められる物なのでビューやトリガーを使うところだが、
パフォーマンスを重視＆汎用性を高めるためにこうしている。

あとどこかでぐぐって見つけた画像を保存するビヘイビア。

あるテーブルに保存したら、自動的にほかのテーブルにメタ情報を保存するビヘイビア
つまりトリガーの代わりだね。

文字コード変換ビヘイビア

仕様が変わって使っていないが、一つのフィールドに複数の値を入れられる配列型フィールドを作るビヘイビア。
（一対多のテーブルを作れというなよ？そんなJOINが発生する重い処理を作りたくないこともあるんだ。
SQL99 で標準規格化されたしね。）それの応用でオブジェクト（シリアライズ）型

それともうひとつあるのだが、これはちょっとアイデア賞物だと思うので自分のブログで書きたいｗ

結構いろいろ使っているなｗ総論としてデータベースの機能を拡張したいときに使っている。

323 = :

>>322
日本語でおｋ
あいかわらず文章下手糞やなｗ
単純なことをわかりにくい表現するの好きやな
前スレから全く変わってねーな

324 = :

>>322
結局cakeライブラリのモデルで実装されてる機能を少し拡張したいときに
ビヘイビアにいれてるんでしょ？

325 = :

>>322
ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。

この自動的て具体的にどういう意味？

326 = :

>>322
ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。

これは前スレで自作ヘルパーでやってなかったか？
パフォーマンスを重視＆汎用性を高めるというのに具体的内容が欲しい

327 = :

>>322
一つのフィールドに複数の値を入れられる配列型フィールド

ＳＮＳのような大規模サイトでもこれ使う機会なんて滅多にないんだが、何作ってんの？

329 = :

>>322
配列型フィールドを使わない人にとっては
激しく必要のないビヘイビアじゃね？

330 = :

>>322
それともうひとつあるのだが、これはちょっとアイデア賞物だと思うので自分のブログで書きたいｗ

恒例自慢きたこれｗ

331 = :

なんだこの過剰反応ぶりｗ

みるからに同一人物のようだが、
ただの使用例に必死すぎだろｗ

332 = :

○○○を使わない人にとっては
激しく必要のない○○○じゃね？

なんにでも当てはまるなｗ
無理やり反論しようとして滑ってる。

333 = :

>>331
>>332
同一人物乙

334 = :

確かに同一人物だが、それが何か？

335 = :

>>333
cakephpとは外れたこと書くな

336 :

CakePHPで開発するアプリを設計する際にUMLで書いてる人いる？
シーケンス図やクラス図なんかどんな風に記述してるかとか見せてもらえると
参考になります。

337 = :

>>336
UMLを使うと従来の方法より効率が落ちる時もある。
なぜなら、従来なら手書きで適当に書いてきた図をUMLでどうやって書けばいいのか調べなければならないから。
書き方が全部頭の中に入った後でなら従来よりスムーズに開発ができるようになるかもしれない
が、しかし、それまでは相当の苦労が必要ｗ
オブジェクト指向開発とUMLとはまた別の話でUMLはオブジェクト指向開発の道具にすぎない

338 = :

>>336
UML？時間の無駄だろ。そんなん書いてたら
工数オーバーするしで誰も喜ぶもんおらんで

340 = :

そういう問題じゃねーだろｗ

343 = :

Cakephpと関係ない話すんなやボケどもが

345 = :

>>340
そういう問題だろｗ

346 = :

俺はJavaをメインでやってるけどＵＭＬは
複雑になってくるクラス間の関連性の構造の手助けとしてＵＭＬを活用することが多い
だから>>339のいってるように複雑なクラスで無ければ必ずしもＵＭＬが必要とは思わない

347 = :

ユースケースは必ず書くけど、シーケンスみたいな実装よりの奴は
実装者が未熟な場合か、処理が複雑なときだけかな。
クラスダイアグラムはモデル限定でこれもテーブル構成が複雑なときだけ。

ユースケースは文書に起こして仕様書にするので必須。

PHPのクラスを自動生成してくれる奴なかったっけ?
あれでCakeのモデルを自動的に管理してくれると楽かも...楽じゃないかw

349 = :

Javaだとクラスが複雑になってしまうんだよね。
正確にはEJBを使った場合だが、同じものを作るにしても
無意味に複雑になりすぎる。
あれじゃあ、UMLが必要になるのもわかる。

350 :

ちょwww おまえら設計書も書かずに開発しちゃってるのかよ、涙がでるな。
それだから「できました」とかいいながらテストしたらバグ出まくりのプログラムなんか量産しちゃうんだよwwww

UMLじゃなくてもいいが、実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ。
時間がかかる、めんどくさい、頭の中にもう仕様書書いてあるから、という奴に限ってたいした技術力じゃないんだよな。
設計書ってのはコーディング作業が楽になるだけでなく、チーム関係者との意識共有や、リリース後しばらくたってメンテが必要になった時に効果がでるもんだぜ。
プロとして仕事でやってるならば当たり前だと思ってるが、ここにはプロはいないのか？