【PHP】Laravel【フレームワーク】 Part.5
レス数が900を超えています。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/ 今までの経験だと自社サービス開発、受託開発問わず、ほぼ確実にエンハンス開発はあるんだけど、このスレでは納品して一切触らないケースがほとんどなの? 一切触らないケースが多いな
中小零細だと継続依頼ってなかなかないぞ >>831
受託開発した後に納品先に切られて別の開発会社に乗り換えられてる説 >>831
触らないケースが多いね
顧客がバージョンアップや新機能追加などの開発費出す余裕がないから エンハンス開発が無い = 作ったシステムがビジネスとして成功しなかった
だからね、ビジネスとして軌道に乗るなら改良もするが、軌道に乗らないきゃ改良なんてしない どの世界でも当然の話しなんだが、金出さないと成功しないからな
初期投資だけで成功すると思ったら大間違いだ >>831
そもそも完成するまでの依頼でその後依頼された事なんて無いからね
メンテなんて安い所に頼めばいいとでも思ってそうだけど
他人のコードを理解する方がよっぽど高度なのにね・・・ >>838
それ、冗談抜きでめちゃくちゃあるよな
あれだけ作る前にやりとりしてたのはなんだったのかと言いたくなる >>838
社内システムとかクローズドなシステムの開発が割と多いからそもそも納品した後で稼働しているか確認する術も無いけどね >>840
>>841
うちもB2Bばかりなんだけど客の担当がノリノリでも、現場が新しいもの使いたがらなくてなかなか移行できない…みたいに見える、想像だけど
納品後も客が管理者IDとPASS変えないから入れちゃうのでたまに見ると、データ増えてない あ、そう言えば納品してサヨナラじゃなかった今思い出した
SSL証明書の更新だけは毎年依頼されるw >>842
え、それちゃんと許可貰って覗いてんのか? >>842
納品したシステムに勝手に入ってデータ監視とか終わってるなLaravelはw >>846
laravelは関係ないけど842の頭はヤバいな クエリビルダしか使わない場合、モデルは書かなくても良いでしょうか? >>848
普通はLaravelのドキュメントに書かれているような
DB::table('tests')->where(条件)->get()
みたいなやり方よりはTestモデルを定義して
Test::where(条件)->get()
みたいに書く方が良い気がするんだけどね
テーブルが複数名でプライマリーキーがidならモデルのクラス作っておけばいいだけだし
(実際にはguardedなどは定義した方がいいけどひとまず置いておいて)
モデルを全く定義しないプロジェクトなんてやったこと無いから分からないがw DB::table('tests')->where(可変)->where(固定)->where(固定)->orderBy(固定)->get()
みたいなのがコントローラに延々並んでいるよりはモデル作って
Test::getSomething(可変)
みたいにした方がスッキリするんちゃう >>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コマンド追加してる人は結構いるってくらい 誰一人としてファットコントローラーがダメな理由を納得出来るレベルで言えないのだから
結局外に追い出した所でそこのコードは同じことになるのだしなぁw
意味ない論議なんだよ お、煽りおじさんがきたぞ
いい天気なんだからぬこの散歩でも行って来いよ コードを書けば行数が増えるのは当たり前で、大きくなるのが嫌だからどうにかしようというのは、そもそもが違うよね。
行数増えて困ってる人というのはIDE使ってないの?何なの? 下手な逆張りしてケンカを煽ろうとしても無駄だぞ
盛り上げたかったらもうちょっとマシな話題持って来いや ファットコントローラ解消してもファットモデルになるだけ 結局どこかには処理を書くのだから別に外に追い出した所でそれがベストですって
言う説明をしていたらそれこそ初心者レベルかと
同じ処理を何度も書かないとか基本的な事を守れていたらいいと思う
そこをコピペとかでやってたりするのは明らかに初心者だろうが >>904
じゃあファットコントローラーは何故ダメなの? ダメな理由が全く納得いかないものしか無いやんw
頭悪いからダメと言うしかないの?www 真面目にここにいる奴仕事で作ってるの?w
お前のコントローラーは実装が数行しか無いの?w
趣味の奴はでしゃばるなと思うわw クラスごとに適切な役割分担をしようって話でファットコントローラーだからとかファットモデルだから全部駄目って単純な話じゃないでしょ
モデルだけで不十分なら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に書くのは至極当たり前に感じるんだが。 レス数が900を超えています。1000を超えると表示できなくなるよ。