元スレ【PHP】Laravel【フレームワーク】 Part.2
php覧 / PC版 /みんなの評価 :
1 :
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
http://laravel.com/
git
http://github.com/laravel
動画チュートリアル(英語)
http://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
http://www.amazon.co.jp/gp/aw/d/4844339451
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク!] (Software Design plus)
http://www.amazon.co.jp/gp/aw/d/4774173134
※前スレ
【PHP】Laravel【フレームワーク】
http://medaka.5ch.net/test/read.cgi/php/1503683914/
4 = :
あーのさー、Laravelってホントに便利なん?
ちらっと見てみた感じ、なんか、RoRとかCodeIgniterとかCakeとかがおかしてる間違いをそのまま引きずってる気がするんだけど?
これ、簡単なWEBアプリならRoRと同じでお手軽かもしんないんだけど
アプリが複雑になってくるとすぐ死なないか?
5 = :
再投稿は甘え
6 = :
前スレで叩かれたからって再レスかよww
9 = :
>>7
だから、アプリが複雑になるとどうせフォットコントローラになるんだろ
って言ってるんだが。
RoRとかCakeとかといっしょで爆裂Controller生成機じゃないか?
いつになったらこれじゃダメだって気づくんだ?
11 = :
複雑化した時に肥大化しないControllerモデルがあるのか?
まぁ表示制御をフロントに任せる限りはバックエンド側はシンプル、フロントエンドは規模なりのサイズになるわけだけど
13 = :
細かい処理はコントローラーから別ファイルの関数呼び出すだけにしてるから
複雑な処理のあるコントローラーも20行ぐらいで収まっているぞ、俺の場合
14 = :
実際ガチのWEBシステムをLaravelで構築しているときって
どういう作りになってるのか見てみたい。
誰かオープンソースでgithubに上げてないのかな
16 = :
Laravelをガチで有意義に使うならVueかReactの習得は必須だと思うんよね
バックエンド側でやること殆どないからイチイチフロントとバックで分業するほどでもないと思うけど
17 = :
今後もVueが活発になったら
laravelはAPIのみって感じが主流になりそうだね
20 = :
正直脱Bootstrapもやってみたいけど他のCSSフレームワークで何がいいかイマイチ分からんのよね
21 :
>>11
よー分からん。一番でっかくなるのはモデルじゃないんか?
素人だから複雑なシステムはわからんけどコントローラが痩せたらモデルがでっかくなりつつある
22 = :
>>12
だから比較対象になるダメじゃない例がないと考察のしようがないだろ
例を挙げろよ例を
24 = :
自演も何も理想的なモデルって一体何なわけ?
25 = :
>>21
書く量が変わるわけではないでしょ。
どこに書くかが変わるだけだから、どこかが減ればどこかが増えるのは仕方ない。
27 = :
Laravelはもはやスタンダードでしょ
28 = 21 :
>>25
なるほど。大事なのは後で読んだ時に分かり易いことでそれでいいんだな。
30 :
>>29
そういう、わけのわからん独自のアーキテクチャで何とかしようとするのやめれ。
31 = :
middlewareにするなら汎用化してくれないとロジックが取っ散らかるので慎重に
32 = :
四の五の言わずに表示系は全部フロントフレームワークにすりゃいいんだよ
33 = 21 :
>>11
よー分からん。一番でっかくなるのはモデルじゃないんか?
素人だから複雑なシステムはわからんけどコントローラが痩せたらモデルがでっかくなりつつある
35 = :
ミドルウェアが独自のアーキテクチャとかマジで言ってるんです?
36 = :
なんか無知を晒してるヤツ何人か居るがまぁ同一人物なんだろうね
37 = :
たとえララベル使わなくてもコードは肥大化するじゃん
38 = :
アーキテクチャとかフレームワークとかミドルウェアみたいなのは全然気にならないんだけど
BootstrapとかLaravelとかjQueryとかみたいな固有名をカタカナで書いてるの見るとなんか「うわっ」って思っちゃうんだよね
なんでだろ
39 :
>>35
そうだよ。だって、本来のmiddlewareって、そういうもんじゃないもん。
Laravelが勝手に言ってる概念じゃん。
41 = 39 :
そんな言い分認めない。
42 = :
>>40
もっとまともな言い訳考えてこい
43 = 39 :
だいたい、MVCどこ行ったんだよ。
うちのMVCでは手が足りないのでmiddlewareさんを助っ人に呼びましたってか?
そんなポンコツ、設計し直せ。
44 = 39 :
あ、オレ、もしかして今核心ついた?
そういうことやってるからしょっちゅうでかい互換性のないアップデートかけてる?もしかして。
45 = :
結構大規模にやってるけどドメインロジックはPOPOのサービス層に書いてるしコントローラは薄く保てる
そもそもMVC2とかただのUIアーキテクチャじゃん
ある程度複雑になればそれぞれのレイヤ、特にMの中身も設計する必要があるのは当然でしょ
46 = :
>>22
>>>12
>だから比較対象になるダメじゃない例がないと考察のしようがないだろ
>例を挙げろよ例を
これあったら誰か教えて
47 = :
どうせオレオレフレームワークが最強って言いたいだけなんだろうけどな
そういう奴に限ってユーザー認証用のパスワードをDBに平文で持つとかいう愚かな事やってる
48 = 39 :
>>45
>ある程度複雑になればそれぞれのレイヤ、特にMの中身も設計する必要があるのは当然でしょ
おまえは本当に分かってないな。
複雑化してきた時の設計をユーザーに委ねてたらフレームワークの意味なくなるだろ。
そういう時の事まで考えて提示して初めてフレームワークなんだよ。
たとえば>>13みたいな事をさ、フレームワークとして提供すんの。
勿論、そのままやったら馬鹿だけどな。
CakePHPが流行ってた頃さ、ModelはDBにアクセスする物と誤解されて
それ以外が全部Controllerに書かれてファットコントローラーだらけになったのな。
で「CakeはDBにアクセスしないModel“も”作れるのに」って言い張ってたやつがいたけど、
根本的に、そういう設計が狂っちゃってんだよ。
49 = 39 :
>>47
お前のレベルが低すぎる事だけは、その発言でよーくわかった。
50 = :
現にここまで理想的なモデルとしての具体例・対案が一切出てない件
みんなの評価 :
類似してるかもしれないスレッド
- 【PHP】Laravel【フレームワーク】 Part.3 (983) - [98%] - 2021/2/12 4:00
- 【PHP】Laravel【フレームワーク】 Part.4 (460) - [98%] - 2021/4/4 4:00
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
- 【PHP】Laravel【フレームワーク】 Part.9 (884) - [96%] - 2022/3/13 12:00
- 【PHP】Laravel【フレームワーク】 Part.8 (148) - [96%] - 2021/8/8 21:30
- 【PHP】Laravel【フレームワーク】 Part.7 (779) - [96%] - 2021/7/9 16:18
- 【PHP】Laravel【フレームワーク】 Part.6 (745) - [96%] - 2021/6/21 6:30
- 【PHP】Laravel【フレームワーク】 Part.5 (568) - [96%] - 2021/5/1 22:00
- 【PHP】Laravel【フレームワーク】 Part.10 (446) - [94%] - 2022/6/6 19:30
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [94%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 (887) - [82%] - 2019/4/23 21:00
- 【PHP】フレームワーク Akelos (129) - [54%] - 2019/5/9 7:46
トップメニューへ / →のくす牧場書庫について