【PHP】Laravel【フレームワーク】 Part.5
レス数が950を超えています。1000を超えると書き込みができなくなります。
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
※前スレ
【PHP】Laravel【フレームワーク】 Part.4
https://medaka.5ch.net/test/read.cgi/php/1613209188/ >>868
1件あたりのデータの取得時間の差はμsレベルだぞ。単にmodelオブジェクトにhydrateするかしないかって話だから。
その上でどれぐらいの同時アクセスを想定してる？そのレベルの誤差を気にする前に、サーバーのスケールアウトを考えるべきだと思うけど？ >>867
故人www生きろ！
てツッコミは置いといて。
それだと条件クエリをビルドしているだけだから、getもfindも論外だと思うな。加えてLaravelではfindは主キーを使って検索するってコンテキストになってるから、getより筋が悪いまである。 >>867
>Test::getSomething()->get()
getSomething()の中でgetもやるから->get()はいらないんだよ、なんならget後の加工までやるぞ
findの方は知らん getSomething()の中でget発行したらダメでは？
あくまでもローカルスコープはクエリの組み立てまでにとどめるべき いやだからLaravelのスコープとは関係ないんだってば
単に便利なgetメソッドを関数として書くだけ、目的はコントローラ内の記述を減らすこと > 単に便利なgetメソッドを関数として書くだけ、『目的はコントローラ内の記述を減らすこと』
こういうのをControllerに書かざるを得ないという仕様な時点で狂ってる。
CakePHPとかと一緒。 >>874
そんな制約はLaravelに無いよ
勝手にそんなアホな実装してる奴がいるだけ アプリのソースをどういう構成にするかは作る側が決めることだよね コントローラにすべての処理を書くのを批判する奴がたまに居るけど
どこに書こうが一緒やん
大規模になればDIでコンストラクタでサービスのインスタンスを受け取る手法もありとは思うが
そもそも殆がDIする必要もないしな >>840
予算の都合だよ
これ以上知るとバカらしくてやってられなくなるぞ >>879
これ実際どんな弊害があるのかな？
モデルに関する処理は長々とコントローラに書かずにモデルに書いて、共通処理は別の場所に書けば、コントローラで処理を書いてもそこまで長々と書くこともない気がする
それをサービスに追い出したところでサービス側がコントローラと同じようになるだけだしあんまり意味がない気がしてならない 共通化できそうなところは共通化して使いまわさないと改修時にコピペ箇所の改修漏れが発生しやすい 複数のコントローラで利用したい処理を1ファイルにまとめたいのですが
CakePHPのヘルパーに相当する機能は何でしょうか。 >>882
継承かトレイトかライブラリ化、用途に合わせて選べ >>882
Laravelは「継承よりコンポジション」てモダンな考え方に基づくから、traitを使うことが多い。 ただ共通化て言葉は、ベテランのエンジニアがよく警鐘を鳴らしているものだから、本当にその共通化が必要なものかはよく考えた方が良い。 ファットコントローラーの害が感覚的にわからないならプログラマとして必要なセンスがない
Cで言うと全部main関数に処理書いちゃってmainがバカでかくなってる初心者みたいなもん その説明では納得しないでしょ。ファットコントローラーがダメな理由は、コントローラーの責務を無視して処理を追加した結果だから。
責務を無視してしまうとMVCの構造が壊れてしまうので、MVCがメンタルモデルとして定着しているエンジニアは、そのコードを読んだり改修することが極めて困難になる。 つかそういう事は10年前1万回議論されて結論出てるんだから
ググレカスって話だよな >>883,884
トレイトを使う場合、のディレクトリに保存するのでしょうか？ >>890
正解は無いんだけど、俺の場合controller用なら、Controllersディレクトリ配下にConcernsてディレクトリ作ってそこに格納する。
このやり方はRails由来だね。ただLaravelの人気パッケージでも取り入れられている手法でもあるので、お勧めしておく。 そういや
php artisan make:trait
ってコマンド結局まだ実装されてないんだっけ？ ファットコントローラーって名前が嫌だからコントローラーは太らさないようにしてる 別に最初はコントローラーファットでよくない？
途中のリファクタリングの過程でファットでなくすりゃいいだけだし 俺はControllersにTraitsってディレクトリ作って入れてたな >>892
そんな議論て過去にあったの？traitてPHP側で実装されたものじゃん？ 自作でartisanコマンド追加してる人は結構いるってくらい 誰一人としてファットコントローラーがダメな理由を納得出来るレベルで言えないのだから
結局外に追い出した所でそこのコードは同じことになるのだしなぁｗ
意味ない論議なんだよ お、煽りおじさんがきたぞ
いい天気なんだからぬこの散歩でも行って来いよ コードを書けば行数が増えるのは当たり前で、大きくなるのが嫌だからどうにかしようというのは、そもそもが違うよね。
行数増えて困ってる人というのはIDE使ってないの？何なの？ 下手な逆張りしてケンカを煽ろうとしても無駄だぞ
盛り上げたかったらもうちょっとマシな話題持って来いや ファットコントローラ解消してもファットモデルになるだけ 結局どこかには処理を書くのだから別に外に追い出した所でそれがベストですって
言う説明をしていたらそれこそ初心者レベルかと
同じ処理を何度も書かないとか基本的な事を守れていたらいいと思う
そこをコピペとかでやってたりするのは明らかに初心者だろうが >>904
じゃあファットコントローラーは何故ダメなの？ ダメな理由が全く納得いかないものしか無いやんｗ
頭悪いからダメと言うしかないの？ｗｗｗ 真面目にここにいる奴仕事で作ってるの？ｗ
お前のコントローラーは実装が数行しか無いの？ｗ
趣味の奴はでしゃばるなと思うわｗ クラスごとに適切な役割分担をしようって話でファットコントローラーだからとかファットモデルだから全部駄目って単純な話じゃないでしょ
モデルだけで不十分ならRepositoryパターンやValueObjectパターンや他のデザインパターンも入れれば良いし、コントローラーとモデルだけで話が完結する話じゃないじゃん >>909
ファットコントローラーはダメという単純な話だよ
ダメじゃないケースはないから >>902
いや普通ミドルウェアとかトレイトに持たせるやろ >>911
コントローラーってRouteに対して固有の処理になるから固有の処理ならしゃーないけど
共通化できる処理ならできるだけ括り出して外に持たせるべきじゃない？ >>912
ミドルウェアとかトレイトならファットになってもいいの？ >>898
>>888で納得できない？もっと掘り下げて説明してほしいなら、どの辺が納得できないか教えてくれると助かる。 コントローラーってのは処理の流れをコントロールするものなんだよ
データの加工みたいなゴチャゴチャした処理をする場所ではない
これだけのことなんだがわからんか？ >>914
処理単位でそれぞれ分けるならファットにならないぞ >>909
ファットコントローラーはとにかくダメだって言ってる奴いるけど、そいつは無視して良い。
何故ダメかは>>888に詳しく書いたから読んでみてくれ。結局のところファットコントローラーてのは、単なる設計ミスの産物だからダメなのであって、もしコントローラーの責務に見合った処理を書いた結果、なおファットコントローラーになってるなら、別に問題無い。 >>918
>>909はよくわかってるやつじゃん。釈迦に説法だった。 馬鹿しか居ないのかなんなのか知らんけど、
『ファットコントローラー』っていうのは状態であって、手法じゃねぇの。
Controllerに書くべき物で溢れてるなら、いいんじゃねぇの？ファットでも。
問題なのは、本来はModelに書くべき処理を全部Controllerに書いている状態の事。
Railsとか使ってMVS分かった気になってるヴァカはModel=DBにアクセスする物…
みたいな腐った誤謬を持ってるけど、
本来ビジネスロジックを書く場所がModelなので、
それがControllerに書いてあったら、
おまえ、ﾌﾟｷﾞｬｰ
なの。わかったか？ヴァカ共 MV"S"ってなんだよ？タイプミスったわ。
よし、ここからSの定義が何なのか議論始めるぞ。 てか、上で俺含めその説明してるでしょ。むしろ、理解してる奴の方が多いぐらいじゃね？ Controllerに書くべき物がそんなに溢れることってある？
余程でかいシステム作ってるのか JavaのSpringFrameworkだと
Controller、Model、View、Repository、Serviceに分かれるな ModelにDaoとRepository両方書いてる奴は居そうだな お前らのソースコードってすごいカルボナーラになってそうだな ああそうかDBアクセスのクエリとかModelに書いてしまえばコントローラーからはメソッド呼び出しだけで済むのか >>925
EloquentてORM使ってんのにDAOて単語が出てくる理由がサッパリなんだが説明してくれる？
その上でRepositoryてDDDのデータ操作レイヤーの話だと思うんだけど、お前はModelに書くことに否定的な立場なの？
上でも出てるローカルクエリスコープは、このデータ操作をビジネスロジックとして表現するための機能だから、俺の認識だとModelに書くのは至極当たり前に感じるんだが。 公式ドキュメントでもクエリビルダのレクチャーはコントローラー内に書いてあるがな DaoもDtoもEntityもRepositoryも全部Modelの役目だよ >>931
Eloquentとクエリビルダの違い理解してない人？ この馬鹿は一体何を言い出したのだ、お前たちよ。
932nobodyさん2021/05/23(日) 17:43:16.84ID:???
DaoもDtoもEntityもRepositoryも全部Modelの役目だよ そういや次スレﾜｯﾁｮｲのあるこっちでいいんじゃね？
【PHP】Laravel【フレームワーク】 Part.5
https://mevius.5ch.net/test/read.cgi/tech/1618480141/ >>932本人じゃないからわからんけど、 MVCを前提にした場合、controllerの役割とviewの役割は具体的に明示されているから、それ以外の全てがmodelにぶち込まれるってことを表現してるんじゃないか？
だから馬鹿とは思わなかったけどな。逆になぜ馬鹿と言い切れるのかその根拠を知りたい。 他のテーブルとのjoin操作までModelに入れるのはなんか違う気がするんだけどその辺どうしてるの？ >>937
人の話聞いてんのかな？ ModelはDBにアクセスする物じゃねぇんだから、
Modelとテーブルが１対１なわけねーーーーーーーだらーーーーーーーーーー！
937nobodyさん2021/05/23(日) 18:01:50.48ID:???
他のテーブルとのjoin操作までModelに入れるのはなんか違う気がするんだけどその辺どうしてるの？ >>937
そもそもEloquent使ってたらjoinなんて使わないでしょ。クエリビルダ使いたいなら、DBファサードになるからmodelは呼び出されず、必然controllerで書くだろうさ。それが嫌なら層を増やすべきだけど、MVC話の文脈とズレていくだろうからそこはスルー。 >>939
お前、Laravelまともに使ったことないでしょ。EloquentModelの特殊性を全く理解できてないように見える。もしかしてアンチサロゲートキーおじさん？ >>933
ラッピングされてるだけで一緒のものやぞ
$any_table = AnyTable::where(...)->where(...)->where(...)->select(...)->oderBy(...)->get();
$any_table = DB::('any_tables')->where(...)->where(...)->where(...)->select(...)->oderBy(...)->get(); EloquentModelつーかActiveRecordて概念を全く理解していないというのが正解か。 >>942
ラッピングしているというのはそうだけど、それ以外は全然違う。まずクエリビルダはModelを介さないのでデータ操作を隠蔽できずcontrollerに操作を書くことになる。さらに結果はmodelへのhydrateの工程がないためDBから受け取ったデータは標準クラスになる。当然castできないから、ぜんぶstring型という悲劇。 別にControllerにDB処理書いてもいいと思うけどな
Laravelのドキュメントも思いっきり書いてるし >>945
まあ大多数の人はそうしてると思うけどね
ただモデル側に書いた方がシンプルなコードにできるってだけでそれでマウント取るのはホント意味わからん LaravelどころかMVCを全く理解してない奴がゴロゴロいるんかこのスレ
だめだこりゃ MVC理解していないのってお前らの大半やろ
Modelに関する処理をModelに置けば
Controllerは何やっても問題無いやろ
それを何の根拠も無くファットコントローラーｗとか言っているのだからｗ
それ外に追い出したらコントローラーの記述が減ってるだけやろｗ ところでお前らLivewireかinertia使ってる？ >>949
落ち着け。それでログ読め。ファットコントローラーを頭ごなしに否定しているのは1人だけだぞ。 Webサービスでの画面遷移について質問があります。
画面Ａ →(POST)→ 画面Ｂ →(POST)→ 画面Ｃ
と、遷移させたいとします。
で、画面Ｃで受信したPOSTデータにエラーがあったら画面Ｂに戻りたい。
このとき画面Ｂでは、画面Ａから先にPOSTされたデータと、画面Ｂで先に入力した値を再表示させたい。
そこで質問ですが、
・画面Ｂや画面Ｃでは、受信したPOSTデータをセッションに保存するように作るのでしょうか？
・画面Ｃから画面Ｂに戻るには、redirect()を使うべきか、それとも $this->画面Bのメソッド(); を呼ぶのがいいのでしょうか？
教えてください。
お願いします。 そういう場合は、画面Bから画面CにPOSTするんじゃなくて、
画面Bから画面BにPOSTして、エラーが無かったら画面Cにリダイレクト >>952
ファットコントローラー否定派は俺以外に少なくとも1人いる。
MVCはMがアプリケーションでVとCは単なるUIなんだよ。Mにビジネスロジックは全部書く。UIがWebだろうがコマンドラインだろうが独立して動けるようにMを書く。
なのでバリデーションやDBアクセスはMに書くべきで、Cには認証やらGET/POSTの処理やらクッキーアクセスetcを書く。
それが本来のMVCだが、Laravelのドキュメントが違ってるなら、厳密なMVCを目指してはいないのだろう。別にMVCだけが正解なわけでもないから。 まー、955が正解だわな。
949みたいなオレオレMVC論を唱える奴がいるところが、ららべらーの次元の低さを如実に表してるな。 >>955
いや、「頭ごなし」に否定してる人はってことね。MVCちゃんと理解して設計してねって話をしてる人が大半だと思ってて、ファットコントローラーはその設計に失敗した結果だからダメって言ってると思うんだよね。
俺が書いたのは>>888や>>918ね。 バリデーションがMって違和感があるんだけどそんなもん？ >>958
LaravelはControllerかその手前のFormRequest、 RailsやCakePHPはModelでやってた気がする。 俺はCakeを触ってたからバリデーションをControllerでやってるLaravelのドキュメントに違和感ある >>957
MVCちゃんと理解して設計したら、ファットコントローラーにはならないというのがMVCの思想なんだけど、違うか？ >>961
そんなことはMVCのオリジナルの論文には書かれてなかったと思う。
元々は、ユーザーのメンタルモデルに沿った形でアプリケーションを再利用しやすいよう分割しようってだけの話だったかと。一体何を読んでその理解に至ったんだ・・・。
↓オリジナル
https://www.semanticscholar.org/paper/The-Model-View-Controller-(MVC)-Its-Past-and-Reenskaug/ff2ada602c96499c0f8a634e26c2c58ef8ec490f >>962
何を読んでって、Skinny Controller, Fat Modelってあちこちで言われてきたじゃん
と思ったらこれってRailsの話で結構古い記事なんだな、今の人は知らん＆また違うのかも知れんな >>962
オリジナルって何だ？MVCの概念自体は1970年代からあるものでその論文？はそれを研究してまとめたものじゃないの？
コンピューターサイエンスにおけるMVCにファットコントローラーの話は出て来ないかも知れないが、
ここではWebフレームワークにおけるMVCの話をしてるんだと思う 捨て垢でもいいのでQiitaに持論をまとめてほしいです Skinny Controller, Fat Modelでぐぐるとキータすぐ出てくるやん
今まで散々議論されてる話題だし レス数が950を超えています。1000を超えると書き込みができなくなります。
