元スレ【PHP】Laravel【フレームワーク】 Part.6

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

301 = :

>>300
laravelのOSSかなりみて回ったけど、FormRequest使ってる奴らばかりだったぞ。その話は疑わしいのでソースを提示してくれ。

302 = :

バッチがーて言ってるやつは、まず具体的にどんな処理を想定しているのか答えてくれ。

303 = :

モデルにバリデーションルール書く場合で
ユーザーのロールによってバリデーションルール変える必要があった時ってどんな書き方してるのか知りたい

304 = :

間違った住所のままDBに登録される
↓
出荷バッチが働き間違った住所のまま伝票に印刷される　※１
↓
間違った住所の伝票が貼られたまま郵便局に持ち込まれる
↓
ご指定の住所に行き当たりませんでしたといって荷物が返ってくる
↓
商品がこないからキャンセルだと客から連絡が来る

おまえらがバリデーションしないせいで月間300件の荷物が返ってくる
1つ送るのに1050円だから1050*300=315000円の損失

そして※1のところで伝票印刷アプリが「取り込みすら無理なデータだけど」ってエラー出すからバッチ処理が止まる
データ修正してバッチを再投入
だが、ほかにも間違ってる住所があるからまたやり直しっていうのを何度も繰り返す

とにかく間違ったデータが入力されてしまうっていうのは損失として大きいんだよ

305 :

>>303
Laravelで普通にできるだろ

306 = :

>>304
うん？バッチってDBから一覧を抽出するバッチの話なの？バリデーションは何の関係があるの？そんなの登録画面でバリデーションすれば良いだけでしょ？

307 = :

>>302
バリデーションが必要なデータを追加するバッチだよ
それを聞いてとうするんだよ

308 = :

>>307
具体的にて書いたはずなんだが。モデルで書けっていってるやつの主張が意味不明だから。

まず、画面で入力と同じ操作をバッチでもやるって前提が理解できない。

俺の経験上、大体のデータは親子関係にあって、入力する画面は分かれている、バッチだとそれらをまとめて投入するから画面とバッチではバリデーションのルールは異なる。

更に、そんなバッチ自体稀だから、わざわざそのためだけにLaravelの標準を無視してモデルに書くって発想が理解不能。

309 = :

モデルに書くのに違和感あるって人はLaravelしかフレームワーク触ったことない人なの？
煽りじゃなくて純粋な疑問

310 = :

そもそもバッチにパラメータなんて基本ないからな
デイリーだとその日が分かればいいだけだし
特殊なバッチのようなものならそもそも管理画面でパラメータ入れて実行やろ

311 = :

>>309
処理の流れからして先にバリデーションするやろ
モデルでするとかそもそも考え方が異常やろ
複数のモデルを使う時、2個目のモデルに投入するまでそこで使うパラメータはエラーが分からんの？w
バカバカし過ぎる

312 = :

>>309
モデルにバリデーションがあるほうがMVCの原則としてはおかしいのだよ。上でも書いたけど、モデルにバリデーションてのは、Active Record由来。
だから、モデルでのバリデーションに違和感持たない人は、Rails以降のなんちゃってMVCフレームワークしか知らないって理解。

313 = :

>>308
どこまで具体的に要るんだ？実際のコード貼れってか？ちょっとそれは今すぐできないんだが
例えば最近やったのでは、1日1回他社がS3に置いたcsvデータを取り込んで、テーブルにレコード追加するバッチ
requiredやuniqueやdateなど普通にバリデーションが必要でバリデーションしたよ
この程度の例も思い付かないなんてどんだけ経験値低いんだよ

314 = :

>>313
経験値ではなくて規模の話だね。そこそこ正規化されたデータしか扱ったことないんで。

あとそれがどれぐらいあんの？画面10あって、そんなのが1、2程度なら、わざわさモデルでバリデーションするようアーキテクチャを変更するのはアホだってことぐらいは、理解してくれるよね？

315 = :

>>312
その辺は一応浅く理解してるけどコントローラーにもリクエストにも書きたくない場合モデルしかなくね？と思った
Cakeでもモデルに書いてたし
他にもっといい場所あったら知りたい

316 = :

>>314
確かにうちは小規模案件が多い、その意味では俺も経験値足りてないが

もちろん不必要な所まで変えなくてもいんじゃね？俺もRequestのバリデーション使うことはある
ただそれだとバッチの時に不便だから、うちではモデルに書いたバリデーションメソッドを、
Webの場合はコントローラー、バッチの場合はコマンドから呼び出すという実装が多い
だから>>257のページみたいにリクエストクラスでやるのがベストプラクティス！と言いきられるとモヤモヤする

317 = :

週末に気持ち悪い奴らだな
みんな可愛い彼女連れて楽しく過ごしてるのにバリデーションごときに熱くなって悲しくならんの？

318 = :

考え方違くね？
モデルに入るデータをバリデーションするんじゃなくてS3にあるCSVデータが正しいフォーマットかをバリデーションするんじゃないの？

後laravelしか触ってないからモデルに書く事に違和感があるんじゃなく
laravelがリクエストでバリデーションする機能を提供してるからその方針を尊重してるってだけ
使ってるフレームワークがビューテンプレートに書くって方針ならそうするよ
自分のやりやすいを優先して得られるものなんてないでしょ

319 = :

>>304
間違った住所のままDBに登録される
↓
出荷バッチが働き間違った住所のまま伝票に印刷される　※１

バッチ動く前に「間違った住所のままDBに登録される」って書いてあるけど、そこでバリデーションが必要じゃん

320 = :

>>315
cakePHPはRailsを真似たフレームワークの代表みたいなもんだから、例としては不適切。

321 = :

>>316
バッチもあるやつだけ、モデルにバリデーションを移しているの？それはそれで大変そうな・・・

322 = :

>>318
そうそう、フレームワークの標準にのることが大事。それを無視して俺流をはじめちゃうと、オレオレフレームワークの亜種になってしまう。
その結果、新規に参画するエンジニアや引き継ぐ場合の学習コストが跳ね上がったり、メンテできなくて匙を投げられるみたいなことが起きる。

323 = :

>> 322
基本的に面倒くさがりだから独自ルールで書いたらどんなルールかをドキュメントに残さないと引き継げないけど
フレームワークの標準に合わせとけば引き続ぎはフレームワークの作法でやってるのでよろしくで終わる
理解できないって話ならそれは本人の技量であってドキュメントを残してないこっちのせいじゃないって突っぱねられる

324 = :

めんどくさいからちょっとまとめてやるわ
バリデーションて言っても厳密には2種類ある
・フォームから送信されたデータのバリデーション
・DBに保存するデータのバリデーション
例を挙げると長くなるので省略する
前者はリクエストで、後者はモデルで担当するのが正解だが
シンプルな要件ではこの2種類が同じになることも多く、その場合はどこに書くか議論の余地が出て来る

325 = :

まとめなくていい
スルー耐性つけろ

327 = :

バッチ処理に向く、向かないって言ってる意味がよく分からん
要は正しいデータ登録できるかできないかって話だよね？
バリデーションの機能そのものの話だよな

328 = :

モデルでバリデーションするって言ってる奴は.envをコミットするって言ってるやつと同一人物だろw

329 = :

スレの総意としてはどっちでもいいだろ

330 = :

なんでスルーするんだ？
有益な話だと思うけど

331 = :

>>321
じゃあそういう時他にどうすればいいの？

332 = :

異常値は入力時に弾いてDBに入れないのがシステム屋さんの考え方。WEB屋さんはDBにも異常値があるものを作るようだ

334 = :

>>331
それぞれでバリデーション書け。理由は、ユースケースが異なるから。結果的に今は同じだからって共通化しようとするのは、経験の浅いエンジニアが犯しやすい過ち。

335 = :

>>334
それLaravelではアンチパターンだよ

336 = :

バッチからとフォームからでルールが異なるってレアケースだし、共通化できる部分はすべきだと思う
あちこちに分散して書くと非常にバグの基になりやすい
それぞれの担当者が別で開発終盤の忙しい時に仕様が変わって片方にしかちゃんと伝わらないとか、超ありがち

337 = :

>>333
それはそれで苦肉の策って感じで嫌だな
絶対駄目でもないけど

338 = :

あらゆるインプットにはバリデーションが必要で、特定のインプット方法にしか使えない形でバリデーションを実装するのはどうなの？っていうだけなんだが。

特定のケースならバリデーションはいらない、っていうのはむしろ例外だから考慮しなくていい。

339 = :

>>335
勝手にLaravelのアンチパターンとか言い出して何様www

342 = :

>>341
設計が悪いと思わんのかw

343 = :

もうLaravelも9が出るというのに未だにFormRequests使ってるやつが居て草
バッチ処理のこと何にも考えてないんだろうね

344 = :

やっぱRails使いたちのほうが圧倒的にレベル高いわ
Laravel使ってる奴らやべえな

345 = :

>>344
そんな化石使ってるやつのほうがヤバいからw

346 = :

>>343
バッチ処理でバリデーションとかまじで笑えるwww
お前開発したことないやろ？w

348 = :

>>341
設計が悪い　以上この話はもう終わり

349 = :

そもそもバッチ処理ってのが何を言ってるかよく分からん
バッチ処理云々言ってるやつは、
まずはバッチ処理そのものについてまずは説明してほしいわ
バリデーション云々の話はまずは置いといて良い

350 = :

>>341
そんなシステムはおかしいのでこの場合のバリデーションを考えるのは時間の無駄です

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【PHP】Laravel【フレームワーク】 Part.9 (884) - [98%] - 2022/3/13 12:00
• 【PHP】Laravel【フレームワーク】 Part.8 (148) - [98%] - 2021/8/8 21:30
• 【PHP】Laravel【フレームワーク】 Part.7 (779) - [98%] - 2021/7/9 16:18
• 【PHP】Laravel【フレームワーク】 Part.5 (568) - [98%] - 2021/5/1 22:00
• 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
• 【PHP】Laravel【フレームワーク】 Part.3 (983) - [96%] - 2021/2/12 4:00
• 【PHP】Laravel【フレームワーク】 Part.10 (446) - [96%] - 2022/6/6 19:30
• 【PHP】Laravel【フレームワーク】 Part.11 (870) - [96%] - 2022/8/28 15:45
• 【PHP】Laravel【フレームワーク】 Part.4 (460) - [96%] - 2021/4/4 4:00
• 【PHP】Laravel【フレームワーク】 Part.2 (917) - [96%] - 2019/9/10 9:15
• 【PHP】Laravel【フレームワーク】 (887) - [84%] - 2019/4/23 21:00
• 【PHP】フレームワーク Akelos (129) - [56%] - 2019/5/9 7:46