>>650
cakeとの比較だと
・認証周りの機能があらかじめ用意されている
・テンプレートエンジンがあらかじめ用意されている
・フロントエンド周りの環境構築が楽ちん
・ファーストパーティとサードパーティに豊富な拡張パッケージが用意されている
・クリーンアーキテクチャ的な拡張がしやすい
・redisなどの外部システムとの連携の設定が簡単

ぐらいかな。

>>651
ご丁寧にありがとうございます。
Symfonyと比べるとどのような点が使いやすいですか？

>>651
ほとんどCakeにも用意されてないか？

自分で調べもせず楽に知ろうとする教えて君うざいよね

>>654
どうした大手勤務君
自分が答えられない質問に他の人が答えているのを見て嫉妬しちゃったの？

cakeは古臭く感じるんだよ
色々用意されていて自由度もそれなりにあるLaravelを使うと他のフレームワークを使う気になれなくなる
homesteadとか環境面も色々あるし便利だなと
個人的な感想だけどね

>>653
そうなの？なら>>651のうちcakePHPでも十分同等と言える点はどれ？

LaravelがなかったらCake使い続けてたと思う
Cakeは一般ユーザーとadminを認証し分けるのや別のテンプレートエンジン入れたりするのが面倒臭かった
誰かが作ったプラグインも色々あったがメンテされなくなったら終わりだし

LaravelのスレでCakeの話するの違うと思う

まぁ大昔は日本で流行っていた訳だし比較のために出すのは別に問題ない気がする

大手勤務君ってLaravelにすごい詳しいけどどうすればここまで詳しく詳しく詳しく

結局バリデーションはモデルでやったほうがベストプラクティスということで決着がついたの？

そんなこと一人しか言ってなかったぞ

>>662
きみ、相変わらずキモいね

>>662
違う
バッチ処理が必要なアプリ→モデルでバリデーションがベストプラクティス
バッチ処理が必要ないアプリ→FormRequestでバリデーションがベストプラクティス

アプリの構成によってベストプラクティスが変わるという結論だよ

すみません教えてください　laravelでプロジェクトを作成すると
プロジェクト直下にartisanというファイルがありこれを使ってコントローラ生成したりなど色々行うと思います。
本番環境にアプリを配置する場合このartisanというファイルは削除したほうがいいのでしょうか？
WEBブラウザからartisanファイルが実行されて変なことにならないか心配しています

>>667
そんなレベルでLaravel使うことのほうが心配だよ

荒らしはスルーで

すみません。別FWだと本番環境にモードを設定するコマンドが用意されており
そのコマンドを実行すると開発にしか使わないようなライブラリや開発専用コマンドなどのファイルを
自動削除してくれていたので今まで気にしたことはありませんでした。
laravelだとそのようなコマンドがないようだったので本番リリース時にどこまで削除すればいいのか
わからなくなって質問させていただきました。

今開発しているアプリがテストデータ程度だと普通なんだけど本番データに近い件数入れたら
なんか一覧を表示する速度が遅いなって思ってたら数年ぶりにN+1を発生させてしまっていたぜ

N+1なんて回避して当然だから自分やらかしていることに気付かず調べてから判明するまで６時間費やした

お前らモハメドの話聞いてないのかよ

LaravelのEloquentにはupdateメソッドとsaveメソッドがありますが
どちらを使うのが一般的なんですか？

>>675
動作が違うので必要な場面で必要な方を使うのが一般的です

相変わらず、ワケワカラン実装してんなぁ…。
作ってる奴がアホなんだろうなぁ…。

>>678
ワケワカランてどういうところがそう思ったのか気になるなー。

初心者はまずドキュメントか本を読んで基礎を学べ

ずっとjavascriptマンやっていて再びphpに戻ってきたらなんかいろいろ苦しい

>>680
その使い方だとupdateでも同じでしょ？
自分はfillした後に何か処理挟むならsave、挟まないならupdateって使い分けしてる
あとコントローラー内限定だよね？その書き方

釣り針デカすぎ

>>684
>>683
「updateでも同じ」って部分を言ってるなら多分勘違いしてるぞ

>あとコントローラー内限定だよね？その書き方

はぁ？　場所によって書き方変わんの？
相変わらず、ワケワカラン実装してんなぁ…。
作ってる奴がアホなんだろうなぁ…。

>>686
お前はせめてPHP初心者卒業してからコメントしろよ
アホなんだからｗ

>>686
横だけど、requestオブジェクトからバリデートした値だけを受け取っている部分があるから、controller限定かどうか尋ねてるってことでしょ。Laravelのこと知らないなら黙ってたほうがいいよ。どうせお前bigintおじさんでしょ？

あえて煽る意味あるの？

>>690
そうなんだよね、結局updateの中身だってfillしてsaveしてるだけだから
あえて->save()分のコード量増やす意味ないと思う
それよりも震えるのはプロパティに値セットしてsaveしてる人ら

>>691
何故？ｗ
そっちが普通やろ
fill()とか常に使っている方が頭おかしい

マスアサインメント知らないアホがなんか言ってるな

このスレ見てるとphp使いとペチパーと揶揄される理由が分かるね

そうか？低レベルなエンジニアはどの言語にも一定いると思うぞ。

>>692
前提としてfillableかguardedをModelに設定してるよね
その値って更新可能なカラム名って感じがするけど
そうじゃなくてcreateとかupdateとかfillの引数で入力される連想配列が保存可能なカラムを定義してるのよ
なのでfillとかを使わないでセットした値はその影響を受けないのね
例えば更新なんかしちゃダメなprimaryKeyの値とかも変更可能なの
$user->id = 10 ;
$user->save();
ここまで書いたら分かると思うけど
こういう実装方法って重大なセキュリティホールの要因になりえるので
気を付けようねって意味を含めて「震える」って書いたの
別に俺はプロパティでセットしてsave呼び出してるからと言って頭おかしいとは思わんよ
上に書いた理由を知らなかったってだけだと思うし
実際、俺も使い始めの時プロパティにセットする実装してたから
こういった理由を知った上でそれでもプロパティで実装する方法を選択してるなら頭おかしいって思っちゃうかな

え、
$user->id = 10 ;
なんて誰が書くの？君の同僚？

>>697
申し訳ない、俺の例がわかりにくかったみたいだね
こんな例が考えられるけどどうかな？
たとえば悪意のあるユーザーがリクエストでis_adminパラメータを送信して
そのパラメーターがモデルのcreateメソッドに渡されてユーザーが自分自身を管理者に格上げする
みたいなケースが考えられるでしょ？
あと、少し慣れてくるとプロパティにセットする事が手間になってきて
foreachで回して値をセットしたりしがち
そうなると完全にやばいよね

> foreachで回して値をセットしたりしがち

すまん、俺はそんな場面に出くわしたことないが、君の職場ではしがちなのかい？

Eloquent式は受け取ったリクエストのタイプによって保存する内容が大幅に違う場合とかには重宝するけどね