のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,904人
昨日:no data人
今日:
最近の注目
人気の最安値情報

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

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    201 = :

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

    203 = :

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

    204 = :

    そんな質問あったか?

    205 = :

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

    206 = :

    普通サブドメインだよな

    210 = :

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

    211 = :

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

    212 = :

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

    213 = :

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

    214 :

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

    215 = :

    「てんかく」な

    216 = :

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

    217 = :

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

    218 = :

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

    220 = :

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

    222 = :

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

    225 = :

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

    226 = :

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

    230 = :

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

    231 = :

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

    232 = :

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

    234 = :

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

    235 = :

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

    236 = :

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

    237 = :

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

    238 = :

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

    240 = :

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

    243 = :

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

    244 = :

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


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について