【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/ >>848
書かなくて良い。でもそんなシステム触りたくないわ。バッチなら良いけど。 >>842
それ大丈夫なの？
依頼があって見てるわけじゃなくて自ら勝手に見てるんでしょ？ >>842
それ許可なくログインはアウトだろ・・・・ > Test::getSomething(可変)
> みたいにした方がスッキリするんちゃう
やってる事が昭和だな。 >>856
どうゆうこと？>>850はローカルクエリスコープの話してるんだなって思って読んでたけど。 すいません。>>737 の質問をした者です。
自己解決できたので一応。
Route::get('/', function () {
return view('welcome');
});
の「'/'」の部分を、サーバーのルートからのファイルパスだと
間違って認識していたのが原因だったみたいです。
htdocsと同階層にLaravelをインストールして、
/htdocs/public/index.phpでパスだけ変更、
サーバーのルートを/htdocs/publicに設定することで
あとはルーティングでどうにでもできそうです。
>>746
で仰ってた意味がやっと分かりました。
色々すみませんでした。 >>857
いやスコープならscopeから始まる名称じゃないと駄目じゃない？
getから始まってるってことは昭和な書き方だよ 確かにローカルスコープを使うにはscopeから始まる名前にしなさいと
Laravelのドキュメントには書いてあるけど 実際はscopeから始まらなくても使えるんだよ 前スレのこういうレスがあったので
パフォーマンスを重視するならクエリビルダを使うってことでモデル不要なのかなと思いました
35 名前：nobodyさん [sage]： 2021/02/27(土) 09:16:39.22 ID:???
リレーションシップで取得可能かつクエリもパフォーマンスに影響が出ないものならeloquent。それ以外はクエリビルダ。 scopeの件理解した、なるほどそういうのがあるのか
でもやりたいことは単にgetという想定なのでメソッドはgetでいいと思う >>859
いやいや、そりゃモデル内で定義するときはscopeGetSomething()だけど、
呼び出すときはTest::getSomething()でしょ。
ただ命名のことを問題にしてるってことは理解した。
それについてはget()まで含むクエリスコープなら、getから始まる名前つけるのは悪くないと思った。 >>863
それ書いたの俺だけど、意図としては原則Eloquent使って、例えば数万件のデータをバッチでfetchするときはクエリビルダ使うってこと。
詳細画面や一覧画面とか表示する分には、クエリビルダのほうが速いって言っても誤差の範囲だから使う理由はない。 故人的にはgetSomethingよりもfindSomethingのほうが好きだな
Test::getSomething()->get()
Test::findSomething()->get()
となるかの違いでしかないけど >>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使ってる？ レス数が950を超えています。1000を超えると書き込みができなくなります。
