>>444-446
小さいころ数人でワイワイ砂場で遊んでたら知らない男の子が後から入ってきたからその子も含めてみんなで遊んでると
他の子が作った山とかを壊したり100万円持ってるとか意味わからん嘘ついたりを「やめて」って何回言ってもやる子だったから
またその子が砂場に来た段階でみんなで別の遊具に移動するようになって
誰もいない砂場でごく短時間だけ「楽しいなー」みたいなこと言いながら遊んでた「あの子」を思い出すからやめて・・・

>>451
長い上に意味不明で読んで損した

未だにバッチ処理とか組んでる老害居るのかよ
.envをコミットしてるガイジまで居るしとんでもない動物園だこりゃ

>>449
他も分からん方が多いわw

>>450
頭の中がおじいちゃんなのよ…
あまり責めないで

零細vs老害

>>450
想定会員数と用途とか情報が足りてないから想定可能なボトルネックは「ある」ものとして設計しなきゃならないと思うから
100万会員/dayで運用開始から現在までって仕様だった場合、どこかで破綻するでしょ

>>451
幼児特有の「アレ」な
幼児特有？w

>>450
例えば自由に停止再開できる有料サービスを契約している会員数もCSVに載せることになった場合でもそうする？

>>457
100万会員/dayの場合OSSのDBで扱えないだろうし言語にPHPを選ばないと思う

100万会員、何？　登録？　アクセス？

毎日100万会員増えるサービスってどんなんや？
100万DAUのサービスならPHP/MySQLのもある、ソシャゲとか結構PHPだし俺も昔モバゲーのゲームをCakeで作った

>>461
注射打つ回数に決まってんだろ！

グラブルがPHPらしいしPHPで出来ないサービスなんて殆ど無いやろな

>>448
何論点ずらしてるのこの人

むしろPHPよりはボトルネックになるのはDBの方じゃないかな？

それより>>459どうするのか気になる

>>459
だからそれも同じ
出力時に計算してCSVに出せばいいだろ

>>462
会員数としか明記されてないので
例えばアプリのインストールやログインとかのレポートなんかを提供するマーケティングツールをイメージした

バリデーションをモデルでやるのってそんなにおかしいか？
データはDBのテーブルに保存されるんだからバリデーションはそれに合わせるべきでしょ
ユーザーIDなんかはカラムにユニーク制約付けて、Laravelのバリデーションでcreate時にユニークチェックする
必須項目はNULL不許可にしてバリデーションでrequired
数値はint型のカラムにしてバリデーションでnumericまたはinteger
みたいになるだろ
テーブルに紐付いたり一番近いのはモデルなんだからカラムの属性はモデルにまとめて書くべき
普通fillableまたはguardedを指定すると思うけど同じようにrulesも書いとけばいいんだよ
コントローラーやコマンドはそれを呼び出して使えばいい

>>471
DBに投入するデータと入力データはかならずしも一致しない
例えば、パスワードなんてハッシュされてしまう

>>471
おかしくないと思うしあってもいいと思うけど
ユーザー属性によってバリデーションルールが変化するサービスの場合はどうするって問題が出てくるでしょ

>>472
完全一致する必要はない、むしろ普通は完全一致しない
けどバリデーションされる情報ってだいたいテーブルに紐付く情報だろ、多少の例外はあってもそこは無視できんだろ

>>473
そんなのどうにでもなるじゃん
Laravelのバリデーションルールにはいくらでも複雑な条件書けるぞ、足りなければルール自作すればいい
動的に変化する条件も書けるぞ

>>474
それ言い出したら、フロントに一番近いとこでやっても変わらんだろ
多少の例外があっても、基本的にフロントから来たデータをバリデーションすんだろ？
そこを議論してもしょうがないんだよ

>>476
・フロントから来たデータをバリデーションする
・DBに入るデータをバリデーションする
この考え方の違いか、俺はずっと後者だったから前者の考え方はこのスレの議論で初めて知った
バリデーションは何のために必要か？と言うとDBに不正なデータを渡さないためだから、後者の方がしっくり来るけど

>>471
Laravelが提供している標準を無視して、そんなオレオレ実装にこだわる理由がわからん。どうしてもモデルでやりたいなら、cakePHPやRails使えば良いのでは？

>>477
それは「なんちゃってMVC」しか知らないからだね。元々MVCは、入力値のチェックをコントローラーの責務としている。
俺はどっちでも良いと思ってるから、その仕組みが提供しているほうに合わせるべきだと思う。それをせずにわざわざ仕組みを変えようとして無駄に工数を使うやつは、仕事ができないやつだと思う。
極論、作るシステムのステークホルダー(エンジニアの除く)にとって、バリデーションがどこで行われているかはそのシステムの価値を決める上で一切関係が無い。

>>478
標準を無視してオレオレ実装にこだわっているわけではない。
モデルに書くのも一理あるでしょ？って言ってるだけ。俺だってFormRequestのバリデーションも使うし。

>>479
なんちゃってMVCで作ってるのはわかっている。本来のMVCでないとダメなんて思ってないし。
Laravelが提供してる方法ってFormRequestのバリデーションのことだろうけど、
モデルに書いてもあまり手間変わらないよ。
そもそも公式の例ではコントローラーにバリデーション書いてる。その
[
'title' => ['required', 'unique:posts', 'max:255'],
'body' => ['required'],
]
なんかの部分を、モデルに持って行くだけだよ。コントローラーでは
$request->validate(SomeModel::getRules());
のように使う。こうすれば他のコントローラーからも同じように使える。条件によってルールが変わる時は引数で指定する。

あのさぁ、アプリの基本って、入口と出口を固める事なのな。
バリデーションは入口、エスケープは出口。

どうしてModelみたいな真ん中でバリデーションしようとする？
こんな基本的な事言わんとわからんの？

>>479
>極論、作るシステムのステークホルダー(エンジニアの除く)にとって、バリデーションがどこで行われているかはそのシステムの価値を決める上で一切関係が無い。

わかりやすい所に書かれていたり、うまいこと共通化できる所はしてある方が
バグの可能性が減って価値が上がるよ。

>>482
真ん中じゃないじゃん。
モデルはデータに紐付くもので、データの入口と考える。
もちろんこれが唯一の正解じゃないから、本来のMVCがとかお前のMVCがどうとかは知らん。

DB投入値の担保は、モデルの引数に型宣言かませばいい
http://speakerdeck.com/twada/php-conference-2016-original?slide=35
これで「出来ていいこと」が明確になる

>>475
実際に書いて試した事ないでしょ？
やったらわかるけどartisanコマンドの時にどうすんのこれってなるから
一つにまとめる事がダメって訳じゃないけど分岐していくやり方は
見通し悪くなるってのと分岐が増えると結合度が上がってどんどん変更に弱くなると思ってる

>>484

ごめん、頭の悪い子と話すの疲れるんだけどさ、

お前が作ってるの、一体何だ？　バラの部品を複数作ってるのか？
何でアプリ全体で見ないで部品単位で見てるんだよ？

空港降りたら検疫して、駅に入る前に検疫して、電車に乗る前に検疫して、県境越えたら検疫して、電車に乗る前に検疫して、バスに乗る前に検疫して、宿に入る前に検疫して…

なんてやると思うか？　国に入ってきた時に一回だけだろ。
最初に１回きっちり検疫すればその後、どんなところを通ろうが関係ないだろ。効率って物を考えろよ。

というか、モデルはデータの入り口って、本物のバカなの？
RDBに対してデータを“出力”する場所だろ。だからエスケープが必要になる。
お前マジで、安全なアプリケーションの作り方とか、全く勉強してないだろ？

DBがモデルに一番近いからそこでバリデーションするって言い張る人に聞きたいんだけど

例えば携帯電話番号の入力フォームでは以下の入力を受け付ける
「09012341234」
「090-1234-1234」
「０９００１２３１２３４」
「０９０－０１２３－１２３４」

DBに格納すれる値は正規化して以下の通り
「09012341234」

って要件を実現するのにどうやってるの？
先に正規化してからバリデーションしてるわけ？

>>484

あと、もう一個言うとさ、
おまえのアプリではModelは常に１つなの？
Modelファイルが複数ある場合、どこでバリデーションするって言ってる？
流石に、各Modelでそれぞれバリデーションするとか言わないだろ？
じゃあ、どこ？　復数のModelの前？
そこはModelじゃなくて、つまりControllerじゃん。

>>488
自分で答え書いてるじゃん
ユーザーの入力とDBに格納する形式が違うなら、
先にユーザーの入力値を整形した上でバリデーションしたらいいだけ

ちなみに、ネットの多数派の意見はどうなんだい？と思って検索してみて最初に出てきたのが、これで、
心の底から脱力した。

http://blog.64p.org/entry/2013/11/26/131914
『言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。』

そういう事してるから、フロントとサーバーサイドでバリデーションルールが違うみたいな事が発生してくるんだろ。

実際、俺がいじるわけじゃないからどこでバリデーションしようとそいつの勝手ではあるんだけどさ、
どこでも同じバリデーションが使えるような実装じゃないと、メンテ大変だろ？

で、この話って元々なんだったんだっけ？

ageてるやつの能書きがキモいって話題
引きこもりは出てくんなよ

バリデーションはデータの受け渡しが発生するたびに行う
１．入力時にJavascriptでチェック
２．フォームがPOSTされるときにバックエンド側でチェック
３．バッチ処理が走るときにチェック
４．ビジネスロジックが走るときにチェック
５．CSVとして出力するときにチェック

少なくとも入力されてからCSVとして出力されるまで5回はチェックされる
なんらかのロジックが走るたびにチェックされるから実際は何十回もする

>>491
いやおかしいだろ
そしたらパスワードもハッシュしてからバリデーションすんのか？

>>494

まーた頭おかしいの湧いてきたし。

内容に関係ないことで頭に血を上らせて、おまえ、脳に障害でもあんのか？

>>489
>>481にコードも書いたからよく見てくれ
俺が提案してるのは、コントローラー（FormRequestでもいいけど）でバリデーションする際、ルールはモデルに書いてあるのを参照するって事だ
Laravel公式のやり方のほんの一箇所変えてるだけなんだよ
その方が使い回しとかメンテしやすくていいじゃない？って言ってる

月曜の朝から熱いねおっさんなのに