私的良スレ書庫

不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterで
ログインするとレス評価できます。登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。

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

php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニュー

みんなの評価 :
レスフィルター : (試験中)

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

201 : nobodyさん - 2019/04/30(火) 20:07:57.39 ID:???.net (+25,+29,-22)

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

202 : nobodyさん - 2019/04/30(火) 20:41:23.89 ID:???.net (-23,-30,-58)

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

203 : nobodyさん - 2019/04/30(火) 21:28:10.16 ID:???.net (+26,+28,-46)

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

204 : nobodyさん - 2019/04/30(火) 21:31:33.76 ID:???.net (+20,+27,-2)

そんな質問あったか？

205 : nobodyさん - 2019/04/30(火) 21:35:17.37 ID:???.net (+33,+29,-19)

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

206 : nobodyさん - 2019/04/30(火) 21:36:34.72 ID:???.net (+11,+18,-1)

普通サブドメインだよな

207 : nobodyさん - 2019/04/30(火) 21:43:53.51 ID:???.net (-29,-30,-52)

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

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

210 : nobodyさん - 2019/04/30(火) 23:59:59.53 ID:???.net (+27,+29,-19)

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

211 : nobodyさん - 2019/05/01(水) 00:17:14.94 ID:???.net (+25,+30,-95)

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

212 : nobodyさん - 2019/05/01(水) 00:19:32.15 ID:???.net (+22,+29,-16)

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

213 : nobodyさん - 2019/05/01(水) 00:40:20.75 ID:???.net (+33,+29,-8)

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

214 : nobodyさん - 2019/05/01(水) 00:42:02.27 ID:FhfsDH51.net (+24,+29,-13)

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

215 : nobodyさん - 2019/05/01(水) 00:46:29.24 ID:???.net (+17,+29,-5)

「てんかく」な

216 : nobodyさん - 2019/05/01(水) 01:06:20.07 ID:???.net (+27,+29,-30)

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

217 : nobodyさん - 2019/05/01(水) 07:54:59.12 ID:???.net (+32,+29,-5)

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

218 : nobodyさん - 2019/05/01(水) 10:27:15.16 ID:???.net (+22,+29,-4)

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

219 : nobodyさん - 2019/05/01(水) 11:12:48.07 ID:???.net (-29,-27,-27)

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

220 : nobodyさん - 2019/05/01(水) 13:06:20.57 ID:???.net (+25,+27,-29)

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

221 : 165 - 2019/05/01(水) 14:38:56.83 ID:???.net (-28,-30,-121)

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

222 : nobodyさん - 2019/05/01(水) 16:02:06.14 ID:???.net (+25,+29,-3)

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

225 : nobodyさん - 2019/05/01(水) 17:14:09.94 ID:???.net (+38,+30,-96)

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

226 : nobodyさん - 2019/05/01(水) 19:00:05.02 ID:???.net (+33,+29,-10)

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

227 : nobodyさん - 2019/05/01(水) 22:15:39.59 ID:???.net (-29,-29,-30)

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

230 : nobodyさん - 2019/05/01(水) 22:38:10.57 ID:???.net (+31,+27,-90)

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

231 : nobodyさん - 2019/05/01(水) 22:41:07.33 ID:???.net (+27,+29,-4)

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

232 : nobodyさん - 2019/05/01(水) 23:22:39.31 ID:???.net (+42,+29,-26)

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

233 : nobodyさん - 2019/05/01(水) 23:35:03.32 ID:???.net (-25,-28,-36)

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

234 : nobodyさん - 2019/05/01(水) 23:36:19.22 ID:???.net (+39,+29,-24)

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

235 : nobodyさん - 2019/05/01(水) 23:42:35.06 ID:???.net (+38,+30,-64)

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

236 : nobodyさん - 2019/05/02(木) 00:11:33.31 ID:???.net (+27,+29,-56)

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

237 : nobodyさん - 2019/05/02(木) 00:17:07.99 ID:???.net (+30,+29,-23)

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

238 : nobodyさん - 2019/05/02(木) 00:45:44.36 ID:???.net (+36,+29,-152)

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

239 : nobodyさん - 2019/05/02(木) 01:14:42.40 ID:???.net (-27,-30,-80)

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

240 : nobodyさん - 2019/05/02(木) 01:27:03.92 ID:???.net (+31,+29,-183)

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

241 : nobodyさん - 2019/05/02(木) 01:43:38.97 ID:???.net (-19,-26,-60)

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

242 : nobodyさん - 2019/05/02(木) 08:40:11.26 ID:vhQh3nzL.net (+0,+29,-22)

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

243 : nobodyさん - 2019/05/02(木) 09:57:18.77 ID:???.net (+21,+28,+0)

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

244 : nobodyさん - 2019/05/02(木) 10:03:57.87 ID:???.net (+25,+27,-26)

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

245 : nobodyさん - 2019/05/02(木) 10:56:32.29 ID:???.net (-27,-24,+0)

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

247 : nobodyさん - 2019/05/02(木) 11:44:03.38 ID:???.net (-27,-30,-25)

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