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

php覧

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

251 = :

>>250
多分日本語で書いてあっても読まないだろうな

257 = :

お前らのためにベストプラクティス貼ってやるよ
http://github.com/alexeymezenin/laravel-best-practices/blob/master/japanese.md

258 = :

>>257
バリデーションはモデルでやれよ
Requestでやるとバッチ処理の時に困るぞ

259 = :

>>258
前もそれ書いてたよね。Laravelエアプかよ。

261 = :

>>260
そりゃそうよ。まぁtailwindCSS使った方が楽なことが多いから。アホみたいにCSS設計とか命名規約とかに無駄な時間使うことも無くなるし。

262 = :

前に書いてたから何なんだ？
エアプって何？
言いたいことがあるなら普通に言えよ

263 = :

>>262
Laravelのフォームリクエストは、外部からの入力を検証するための機構だからモデルでやれって主張はアホすぎるってこと。MVCでは、入力値の検査はコントローラーの責務。

RailsとかがModelで検査してるのは、MVCよりActiveRecordのルールを優先した結果に過ぎない。

そもそも画面やAPIからの入力とバッチの入力のバリデーション仕様が同じになるケースなんてまず無いと思うんだけど？

誰にも相手にされなかった主張を、また繰り返すのはやめたほうが良いぞ。

266 = :

>そもそも画面やAPIからの入力とバッチの入力のバリデーション仕様が同じになるケースなんてまず無いと思うんだけど？

え、そんなことはなくない？
1つのテーブルにデータを追加するシンプルな要件だと、WebからフォームをPOSTしてもバッチで追加してもルールは一緒になるだろう
エラーメッセージの出し方とかは異なると思うけども、バリデーターをそれぞれ別に書いたりはしないと思う

267 = :

>>260
どのフレームワークを使うか選択できなかったっけ？

268 = :

モデルに紐付かないバリデーションはどこに書けばいいですか？

270 = :

議論する際「どこでやるか」と「どこに書くか」を混同しないようにしないといかんな。
モデルに書いてもリクエストに書いても、流れ上は「コントローラーでやる」と言っても間違いではない。

271 = :

議論するなら、「俺はAに書いてる。なぜなら○○だからだ。Bに書くと○○で駄目だ」
って理由まで答えないと成立しないけどな

272 = :

>>269
268です。ありがとうございます。
ちなみにそれだと、
Aというルートではコントローラーにバリデーションを書き、
Bというルートではモデルにバリデーション書く、
というようにバラバラになってしまうんですが、気にしないほうが良いのでしょうか？
それとも一律コントローラーに書くほうが良いのでしょうか？

274 = :

>>270
それが許されるなら何でもありですがな

275 = :

バリデーションのルールをコントローラーに直書きするのがよくないと思う
使い回したりメンテしやすいよう別の場所に出して、コントローラーはそれを呼び出すだけにしたい
じゃあどこに書くか？となると多分モデルなんだが、LaravelのRequestに書く仕様はちょっとビックリした
一見理に適っていて便利でもあるけど、既出の通りコマンドから同じバリデーションを実行する場合は一工夫必要になる

276 = :

>>275
コントローラーのメソッドから呼び出すのは良くて、コマンドのメソッドから呼び出すのが良くない理由もお願いします。

277 = :

リクエストのrules()メソッドにルールがまとまって、コントローラーとかにルールが散らばらなくてメンテしやすいと思うけどなあ

278 = :

お前ら細けえな
好きなように書けよ
どうせ誰もメンテしなくなるんだし
バリデーションなんて動けばいい

280 = :

>>272
そうだねそうなるよ

281 = :

>>263
逆にフォームからとバッチからでバリデーションルールが異なるケースってどんな時だよ
そんなの見た事ないわ

282 = :

コントローラにバリデーションルールダラダラ書いたコード納品されたら俺だったらキレるわ

283 = :

メンテしない案件でも納品直前に「やっぱりパスワードの文字数○○文字以上に変えてくれ」なんて依頼よくあるからなあ
「空の時に表示が崩れる」という理由で本来必須じゃなかった項目をrequiredに変えたり
クライアントは馬鹿だから色々予期せぬ事が起こる

284 = :

>>282
じゃあ今度からはモデルにルール書くね

285 = :

メンテ＝他人に見せることばかり考えてるやついるな
メンテは自分が見てわかりやすくするためのものでもあるだろ
好きなように書いてて、半年後に見ても思い出せるのかよ

286 = :

Laravelってバリデーションどこに書くかでも大論争になるんですね
Symfony選んどいてよかった

287 = :

laravel使いは年収低いから仕方ない

288 = :

年収高い言語だと論争が起きないの？

289 = :

言うほど大論争になってるか？
ボケがツッコまれてるだけやろ

291 = :

間違ってたら考えを改めたいから言って欲しいんだけど
何でFormRequestがやってるバリデーションって入力された値が想定してる値かってバリデーションなので
その先にあるであろうテーブルとかを考慮しちゃいけないものだと思ってる
例えば同じテーブルに入力されるデータでも管理者権限と一般ユーザー権限でバリデーションルール変えたいってケースなんてザラだし
モデルに入力される値のバリデーションは持てるの担当範囲外でその担当は
おそらくバックエンドにあるデータベースが受け持ってて入力値が正しくない場合
Exceptionって形で戻してるって解釈してる
違うかな

292 = :

フレームワークなのに決まってないのかよ

293 = :

バッチ処理のことを考慮したらFormRequestクラス使うのはありえないんだけどね
ここはレベルが低いからそこまで理解できないらしい

294 = :

今日もクソ暑い　毎年思うんだけどなんか１年のうちで暑くなる時期あるよな

295 = :

>>293
正直俺もFormRequest使ってるぜってどや顔でこのスレの住人に言われたときは愕然としたな
バッチ処理何も考慮してないよな　こいつらマジでバッチ処理どうやってるんだろうか

296 = :

いうほどバッチ処理なんてあるか？
なんの処理を気にしてるわけ？

297 = :

バッチ処理なんてそもそも間違った入力を渡す事なんか無いやろｗ
頭悪すぎｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

298 = :

>>297
こういうやつの為に、バッチにもバリデーションが必要なんだよな。

300 = :

もうCloseされちゃったけど最近のissuesでもFormRequestsはバッチ処理に向いてないから廃止しようって話あったよね
やっぱりコミュニティでもモデルにルール書く人が大半らしい

前へ 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