のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,914人
昨日:no data人
今日:
最近の注目
人気の最安値情報

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

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    451 = :

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

    452 = :

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

    453 = :

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

    454 = :

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

    455 = :

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

    456 = :

    零細vs老害

    457 = :

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

    458 = :

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

    459 = :

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

    463 = :

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

    464 = :

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

    466 = :

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

    467 = :

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

    468 = :

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

    469 = :

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

    470 = :

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

    472 = :

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

    473 = :

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

    474 = :

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

    475 = :

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

    476 = :

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

    477 = :

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

    478 = :

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

    479 = :

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

    480 = :

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

    482 = :

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

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

    483 = :

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

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

    484 = :

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

    485 = :

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

    486 = :

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

    487 :

    >>484

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

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

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

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

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

    489 = :

    >>484

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

    491 = :

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

    492 = 487 :

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

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

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

    493 = 487 :

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

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

    494 = :

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

    496 = :

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

    498 = 487 :

    >>494

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

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

    499 = :

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

    500 = :

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


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

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


    トップメニューへ / →のくす牧場書庫について