【PHP】Laravel【フレームワーク】 Part.2

テンプレ追加修正お願いします

Laravel
ウェブ職人のためのPHPフレームワーク

本家
https://laravel.com/

git
https://github.com/laravel

動画チュートリアル(英語)
https://laracasts.com/

日本語
http://laravel.jp/

書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
https://www.amazon.co.jp/gp/aw/d/4844339451

Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
https://www.amazon.co.jp/gp/aw/d/4774173134

※前スレ
【PHP】Laravel【フレームワーク】
https://medaka.5ch.net/test/read.cgi/php/1503683914/

まぁ1人でやるような小〜中規模案件でも使い勝手はいいフレームワークだと思うけどね

>>155
それはどういう管理画面なの。
納品先のユーザが使用する管理画面？
それともアプリ製作者が使用する管理画面？

>>158

何を言っているのかわからないんだが、
公開サイトのファイルも、管理画面のファイルも、
全部同じプロジェクトの中に入ると言っているのか？

>>160

例えば、ネットショップを作るとする。
公開画面でユーザが買い物をする。
管理画面で注文について管理する。
当然双方での料金の計算ロジックは同じではなければならないから、
モデルに相当するものは共有したい。

どうするつもりか教えてくれ。

例が具体的過ぎて学校の宿題か
今度実装するアプリについてここで聞いているように思えるｗｗｗ

namespace分けろよ

\App\Models 共通のモデル
\App\Frontend\Http\Controllers
\App\Admin\Http\Controllers

こんな感じで別々にするんだよ。

間違っても App\Http\Controllers\Admin,Frontend にするなよ。

従来の方法で良いんでは
AdminController作ってログインユーザーのroleがAdminのみ受け入れる

>>161
Laravel使ってないから参考にならないだろうけど講演で聞いた限りでは
YahooとAmazonは、買い物画面と管理者画面は同じプロジェクト内で作っている

固定観念の塊って感じw

>>155
無理に擦り寄って来なくていいってば

一般画面と管理画面でnamespace分けるでしょ

こーれはまた、チンパジーだらけだな。
お前らのプロジェクトが火を吹きまくる未来が良く見えるぞ。

namespace分ける馬鹿ばっかりだなぁ
だからお前らのアプリは産廃になるんだよ

>>167

そいつらは自分のところのシステムであるから如何様にも出来ようが、
お前達のプロジェクトがお前たちのさじ加減でどうにかなると良いのう。
はーはっはっは。

>>173
自分は>>162の場合どのように設計するつもりなの？

>>171
Laravel誕生のころからずっと業務システムに使ってるけど
Laravel製のプロジェクトで今まで火を吹いたことないな。
別プロジェクトのDjangoとFuelPHPは吹きかけたけど

>>174

勿論、そのように設計するに決まっておろう。
同じプロジェクト内に作るが、
別のサイト単位で作るのじゃ。
馬鹿め。
Laravelとやらにそれができるのか？
お前にサンが救えるのか。

>>176
そりゃ確かにLaravelはできないね。Symfony2の方がきれいに作れそう。

>>176
その作り方はLaravelでは無理ですね。
そもそもそういうサイト設計するならLaravelは候補にすら上らん

Laravelで作った決済系のサイトだとこいつが有名ですね
https://github.com/Laracommerce/laracom

サイト単位はLaravelでもできるぞ

>>177-178

では、上の方でnamespaceなどとほざいていたチンパンジーどもはなんであったのだ？

>>179
このショッピングサイトのソースだとnamespace方式でやってるな

>>181
現状最高だと思えるフレームワークは何ですか？

>>183

お前はLaravelとやらを使っておれば良い。

普通に複数サイトもやってるけど
パッケージに分けなよ

>>184
お前が未来のフレームワークについて語ろうって自分から
言ってきたんだろうが

幼稚な嵐にかまうなよ……うれションして喜んでるだろうが

Laravelスレってみんな技術力低すぎないか？
AFYaLSZi様の言っていることはもっともだと思うんだが

様付けとかｗｗｗ
ID消して自演かよｗｗ

様とかこいつ頭大丈夫か？
AFYaLSZiが一番技術力低いんだが

>>181
Laravelはマルチプロジェクトの概念がないからnamespace で分けるんだよ。
パッケージの使い方としては正しい。ただ設定値はフロントと管理で共通だからな。まぁ普通はサブドメインを分けて、ルーティングも分ければマルチプロジェクトになるのでそれで十分だろ。

このスレでまともなの俺とAFYaLSZiも含めて3〜4人ぐらいだな。
フレームワークに使われて自分の頭で考えるの放棄してるやつばっか。

お前ら平成最後の日に何やってんだよ
日本人なら日本人らしくアニメ見るとか漫画読むとかゲームするとかしろよ

俺、仕事しながら令和迎えるんだ
日本人は24時間365日仕事し続ける生き物だからね
日本人ぽいでしょ
あはははは

頭いい人はららベルより素晴らしいオレオレフレームワーク開発してよぉw

LaravelでDoctrine使ってる人いる？一度プロジェクト見た気がするんだか見つからない。
ActiveRecordよりEntityManagerのほうが集約コントロールしやすいので好きなんだが。

Laravel+Reactはいいぞ

このスレでまともなの俺とAFYaLSZiも含めて3〜4人ぐらいだな。
フレームワークに使われて自分の頭で考えるの放棄してるやつばっか。

>>196
これのこと？
https://www.laraveldoctrine.org/

露骨な自作自演始まったなw

Laravelが他のフレームワークと比べて
勝っているところと負けているところは何？

>>201
771 nobodyさん sage 2019/04/17(水) 08:51:04.13 ID:???
フルスタックなところかな。キャッシュ、シュケジューラ、ジョブ、ミドルウェア、認識、なんでも設定すればすぐ動く。英語で out-of-the-box って言うんだっけ？箱から出してすぐ使えるってやつ。

誰も一般画面と管理画面の実装方法答えられないのかよ。

そんな質問あったか？

別人だが俺も>>191みたいにサブドメイン切って置いてるな
DB共通にしつつユーザー認証用のテーブルだけ別のものに差し替えて認証するようにしてる

普通サブドメインだよな

基本的にデバッグ時は8000番でやってるからルート以外に置くの面倒なんよね

管理者用の認証テーブル使いたい場合はテーブル作って管理画面用プロジェクトのapp/User.phpに
protected $table = 'administrators';
とか足しとけばそっちのテーブル見に行くようになるし

>>207
auth.php に定義追加すれば Administratorモデルで認証できるよ。
マルチユーザで使えるように設計されてる。

>>143
SyouhinモデルにmaxKosuuを作ってええとカスタマーと1x複数になるのか？
商品を受け取ってバリデーションに渡すと

お前らはLaravelで和暦対応どうした？

和暦使うような糞なシステムはないよ
和暦は役所書類のみ、それ以外は西暦でってのはビジネスの常識
昔はごくごくたまに会員情報の生年月日で使うことがあったが今は個人情報をできるだけ入れない作りが主流

大学関係の契約書だと和暦が多いね

この前「最近点画にハマってる」って言ったら変な顔された

TENGAにハマったまま平成が終わったのか

「てんかく」な

役所と近いところもまだまだ普通に和暦だよ
保育園とか学校とかね
事前に準備して4/2に対応終わったけど

>>213
そんなん言葉のパッと聞きで何言ってるか分かんないに決まってるだろ

>>165
こういう分け方なんで駄目なのか教えてもらえると嬉しい

昨日の ID:AFYaLSZi様の技術力の高さは素晴らしいね
Laravelスレ全員が目指すべき人だよ

令和時代のLaravel始祖の誕生であった

>>218
疎結合にするためだな。FrontendとAdminはControllersの下位の概念ではないだろ？
AdminのためのModels,Http,Command
FrontendのためのModels,Http,Commandがあるんだ。
共通のものがあればAppの下でいい。
Adminをゴソっと消せば全てが消えるし、Frontendは何も関係せず動き続ける。お互いが交差しないようにパッケージを定義するんだ。

>>221
どちらかというとプログラム初心者的な質問なのに答えてくれてありがとう

>>221
Route::group['prefix'=>'admins']にしてるワイはやっぱおバカだったのか…
一応アドミニフォルダにコントローラはしまってるけど

namespace見たらApp\Http\Controllers\Adminでワロタ…

まぁ必ずやらなきゃいけないようなことでもないから自分のプロジェクトに合わせて好きに作ればいいよ。
namespaceをうまく分けるコツはuse文がなるべく少なくなるように定義するんだ。namespaceの上下内で完結するようにする。同レベルの横のnamespaceが3つも4つも出現したら何かが間違っている。
うまくやれば外部に露出するクラスがものすごく減る。

>>225
自然と意識できるようになるまでまだ先は長いな…たぶん

標準搭載されてるServiceManagerはオーバーライドできるけど、それやるとapp.phpを入れ替えないといけんのよね。
オーバーライドすんなってことなのかな。
でもログ周りとか微妙なんだよね。

>>227
ServiceManagerってなんだっけ。ServiceProvider のこと？自分はガンガン置き換えてるよ。

>>228
ああ、申し訳ないProvider。
logとかevent周りとか、こいつら置き換えて使ってる？
container作られる時に、結構余計なことしてるのよね。。

>>229
defer付いてるやつは遅延ロードだから使わなきゃ動いてないよ。
logは標準の定義は残して使いつつ、logger.hoge の名前で別インスタンス追加して必要なときに取り出してる。
だいたいこれで事足りる。
標準のプロバイダを継承してカスタマイズしなきゃいけなかったのは認証とメールだけかな。

お前らのオレオレカスタマイズ内容晒してけ

>>230
deferついてるならそれでいいんだけど、kernelの流れで読み込まれる連中でも、要件によってはそれなりにいらない事してるんだよね。認証周りは同じくカスタマイズしたけど結構めんどかった。
Facadeのメリット活かしつつ機能を取捨選択してると魔改造になっちゃうんだよなあ。

とても使いやすいし揃ってるframeworkだから、欲張ってしまうw
唯一eloquentだけはベンチとって愕然としたなー。あれは商用では使えないと思った。

>>232
ある程度の諦めは必要かもねー。自分で使わないからってFacade削除したら内部とか追加したライブラリで呼んでたとかあるから標準機能は触らないのが無難かもしれん。

>>234
そう。前者もあるけど特に後者が怖くて、標準の機能を削るって選択はなかなか出来ない。バージョンアップの時のオーバーヘッドがこれによって増大するから。ある前提で組まれてるものだから当然なんだろうけど。
削らないが無難。同意ですなあ

ゴリゴリにチューニングするフレームワークではないので機能追加はしても削除はしない方針です。
パフォーマンスが必要になったら札束で殴るしかない。

>>233
そんな遅い？使いにくいのは否定しないけど速度は他と大差ない気がする。
というよりORMでそこまで遅くなる部分があるとは思えないんだよな。

>>237
ちょっと言葉足らずだった。パフォーマンスがシビアに要求されるシステムでは使えない、って感じ。もちろん速度とコーディングの利便性がある程度バーターになるのはわかるけど。
Doctrine単体とかとの比較なんで、同じレイヤーの他ORMとの比較ではないよ。
というのもLaravelでパフォーマンスチューニング、いくつかの案件でやったけどほぼほぼeloquentがボトルネックだった、ってとこからきてる

Eloquentはマジックメソッドを多用したラッパーなんでオーバーヘッドはどうしても増える、PHP8のJITに期待
現状はcursor、バルクインサート、自作のバルクupsertなどで極力DBアクセス数を減らしとくしかない

うーん、なんかイマイチ信じがたい話ではあるな。
マジックメソッドについてはクラスのメタデータキャッシュして2回目以降の呼び出しは速いはずだし。
例えばDoctrineはアノテーション使ってるし遅くなる要因はこっちの方が大きそう。
そもそもマッピングは枯れた技術ではあるので遅いなら他のフレームワーク参考にして同程度まで速度改善できるず。
フレームワーク全体で遅いなら理解できるけどORM単体でそんなに差がでるとは思えないな。クエリが遅いとかなら理解できるけど。

>>240
いや、queryが遅いとかではなく、リレーションシップをCollectionで表現したり（出来たり）するじゃない。そもそもそういう使い方をされる事による速度の劣化であって、同じ使い方をすればdoctrineとかでも同じ結果になってただろうとは思う。

お前達はなんでそんなフレームワークを使っているんだ？
修行でもしているのか？

使わない方が修行だと思うけどw

構造的セキュリティ担保するの面倒だしな

とりあえずmixがとても便利

Laravelのhelperかなりいいよね。関数単体もそうだしCollectionも良い。
PHPはどうしても配列プログラミングになっちゃうからCollectionを使い倒してほしい。

よく使うのはarray_get, pluck, tap, with,abort_if, throw_if, collectかな？
Collectionだとeach map first filter pluck。

>>245
現行モダンフロントのシステム作る上でFirebaseやAWS Lambdaやみたいなサーバレス以外では最後の砦感あるよね
ExpressみたいなNode系フレームワークは新規に手を出すには日本語情報少な過ぎるし(日本語情報は大規模修正入る前の旧版ばかり)

mixってwebpackのラッパもしくは代替みたいなもん？

>>246
全然知らねぇんだけど、helperってもしかしてHTMLの自動生成機能の事？
アホか。要るか、そんなもん。

mix? gulpでいいだろ。馬鹿か！？

なんでLaravelのアホは、ガラパゴスジャパンじゃあるまいし、独自規格ばっかつかいまくるんだよ。

>>250
そのhelperではない

標準規格がゴミだから標準をラップした独自規格作るんでしょ。

>>254

おまえ、gulp様のどのへんがゴミなのか、Yeah!

gulp使うんだったらwebpack使ったほうがまし

javascriptツールの話は他スレでやれよ

>>256
同意