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

[過去ﾛｸﾞ] 【PHP】Laravel【フレームワーク】 Part.2 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

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

222: 2019/05/01(水)16:02 ID:??? AAS
>>221
どちらかというとプログラム初心者的な質問なのに答えてくれてありがとう

223: 2019/05/01(水)16:41 ID:gx0atIKK(1/2) AAS
>>221
Route::group['prefix'=>'admins']にしてるワイはやっぱおバカだったのか…
一応アドミニフォルダにコントローラはしまってるけど

224: 2019/05/01(水)16:44 ID:gx0atIKK(2/2) AAS
namespace見たらApp\Http\Controllers\Adminでワロタ…

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

226: 2019/05/01(水)19:00 ID:??? AAS
>>225
自然と意識できるようになるまでまだ先は長いな…たぶん

227(1): 2019/05/01(水)22:15 ID:??? AAS
標準搭載されてるServiceManagerはオーバーライドできるけど、それやるとapp.phpを入れ替えないといけんのよね。
オーバーライドすんなってことなのかな。
でもログ周りとか微妙なんだよね。

228(1): 2019/05/01(水)22:18 ID:??? AAS
>>227
ServiceManagerってなんだっけ。ServiceProvider のこと？自分はガンガン置き換えてるよ。

229(1): 2019/05/01(水)22:23 ID:??? AAS
>>228
ああ、申し訳ないProvider。
logとかevent周りとか、こいつら置き換えて使ってる？
container作られる時に、結構余計なことしてるのよね。。

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

231: 2019/05/01(水)22:41 ID:??? AAS
お前らのオレオレカスタマイズ内容晒してけ

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

233(1): 2019/05/01(水)23:35 ID:??? AAS
とても使いやすいし揃ってるframeworkだから、欲張ってしまうw
唯一eloquentだけはベンチとって愕然としたなー。あれは商用では使えないと思った。

234(1): 2019/05/01(水)23:36 ID:??? AAS
>>232
ある程度の諦めは必要かもねー。自分で使わないからってFacade削除したら内部とか追加したライブラリで呼んでたとかあるから標準機能は触らないのが無難かもしれん。

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

236: 2019/05/02(木)00:11 ID:??? AAS
ゴリゴリにチューニングするフレームワークではないので機能追加はしても削除はしない方針です。
パフォーマンスが必要になったら札束で殴るしかない。

237(1): 2019/05/02(木)00:17 ID:??? AAS
>>233
そんな遅い？使いにくいのは否定しないけど速度は他と大差ない気がする。
というよりORMでそこまで遅くなる部分があるとは思えないんだよな。

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

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

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

上下前次 1-新書関写板覧索設栞歴

あと 762 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.010s