TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
Perl6/Parrotスレ - Part2
ガチでオンラインショップ構築ソフトを作ろうと思う
☆三　【 スクリプト改造工房 PART 9 】　★三
【管理】Trac使ってみよう【してみよう】
このCGIを作っちゃおう。
symfony PHPフレームワークpart2
七行プログラミング
●CGI作成に愛の手を・・・●
あなたの開発環境は?
一人で始めるWEB起業何が一番面白いかな？ 5案目

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


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

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.2ch.sc/test/read.cgi/php/1503683914/

2 ：
魔法少女ララベル
https://www.nicovideo.jp/tag/%E9%AD%94%E6%B3%95%E5%B0%91%E5%A5%B3%E3%83%A9%E3%83%A9%E3%83%99%E3%83%AB

3 ：
createを使って更新するのとモデルをsaveして更新するのどう違うんやろ。
createの時だけguardedを設定しないといけないとかそもそも複数代入ってどういうことやねん。もーなんじゃいな

4 ：
あーのさー、Laravelってホントに便利なん？
ちらっと見てみた感じ、なんか、RoRとかCodeIgniterとかCakeとかがおかしてる間違いをそのまま引きずってる気がするんだけど？
これ、簡単なWEBアプリならRoRと同じでお手軽かもしんないんだけど
アプリが複雑になってくるとすぐ死なないか？

5 ：
再投稿は甘え

6 ：
前スレで叩かれたからって再レスかよｗｗ

7 ：
6 名前：デフォルトの名無しさん[sage] 投稿日：2019/04/29(月) 02:19:44.72 ID:l/Mc2djO
Laravelとそれ以前のフレームワークの違いってLaravelはフロントエンド側のフレームワークとの連携機構がしっかりしてるから
PHP側のControllerはリクエストに応じてDBの読み書きさえやってればあとの制御はフロント側任せにできるとこだと思うんよね

https://mevius.2ch.sc/test/read.cgi/tech/1555718306/6

8 ：
Laravel-Mixは便利

9 ：
>>7
だから、アプリが複雑になるとどうせフォットコントローラになるんだろ
って言ってるんだが。
RoRとかCakeとかといっしょで爆裂Controller生成機じゃないか？
いつになったらこれじゃダメだって気づくんだ？

10 ：
フォットコントローラｗｗｗｗｗｗｗｗ
ファットだろｗｗｗｗ

11 ：
複雑化した時に肥大化しないControllerモデルがあるのか？

まぁ表示制御をフロントに任せる限りはバックエンド側はシンプル、フロントエンドは規模なりのサイズになるわけだけど

12 ：
>>11
前スレでも言ったけどその時点でLaravelはダメなんだよ。
というかRoR、Cake、Laravel、Symfonyこれらみんなダメ

13 ：
細かい処理はコントローラーから別ファイルの関数呼び出すだけにしてるから
複雑な処理のあるコントローラーも20行ぐらいで収まっているぞ、俺の場合

14 ：
実際ガチのWEBシステムをLaravelで構築しているときって
どういう作りになってるのか見てみたい。
誰かオープンソースでgithubに上げてないのかな

15 ：
フロントエンドフレームワーク利用手順

・Node.js未導入の場合
# yum install nodejs
# npm install -g n
# n latest
# npm install -g npm

Vue.jsを使う場合
$ npm install
$ npm run watch

Reactを使う場合
$ php artisan preset react
$ npm install
$ npm run watch

後はresources/js内のファイルを編集すれば自動ビルド

16 ：
Laravelをガチで有意義に使うならVueかReactの習得は必須だと思うんよね
バックエンド側でやること殆どないからイチイチフロントとバックで分業するほどでもないと思うけど

17 ：
今後もVueが活発になったら
laravelはAPIのみって感じが主流になりそうだね

18 ：
ガッツリ組むならReactの方が後の再利用性はいいと思う

19 ：
うちはjQueryとBootstrapでゴリゴリだわ

20 ：
正直脱Bootstrapもやってみたいけど他のCSSフレームワークで何がいいかイマイチ分からんのよね

21 ：
>>11
よー分からん。一番でっかくなるのはモデルじゃないんか？
素人だから複雑なシステムはわからんけどコントローラが痩せたらモデルがでっかくなりつつある

22 ：
>>12
だから比較対象になるダメじゃない例がないと考察のしようがないだろ
例を挙げろよ例を

23 ：
>>22
自演乙

24 ：
自演も何も理想的なモデルって一体何なわけ？

25 ：
>>21
書く量が変わるわけではないでしょ。
どこに書くかが変わるだけだから、どこかが減ればどこかが増えるのは仕方ない。

26 ：
BootstrapをベースにscopedにSCSS書けるのが便利過ぎて他に移行する気が起きない

27 ：
Laravelはもはやスタンダードでしょ

28 ：
>>25
なるほど。大事なのは後で読んだ時に分かり易いことでそれでいいんだな。

29 ：
Controller肥大化させん為にMiddlewareとかViewComposerとか幾つか回避策もあるんだけどね

30 ：
>>29

そういう、わけのわからん独自のアーキテクチャで何とかしようとするのやめれ。

31 ：
middlewareにするなら汎用化してくれないとロジックが取っ散らかるので慎重に

32 ：
四の五の言わずに表示系は全部フロントフレームワークにすりゃいいんだよ

33 ：
>>11
よー分からん。一番でっかくなるのはモデルじゃないんか？
素人だから複雑なシステムはわからんけどコントローラが痩せたらモデルがでっかくなりつつある

34 ：
ミスった

35 ：
ミドルウェアが独自のアーキテクチャとかマジで言ってるんです？

36 ：
なんか無知を晒してるヤツ何人か居るがまぁ同一人物なんだろうね

37 ：
たとえララベル使わなくてもコードは肥大化するじゃん

38 ：
アーキテクチャとかフレームワークとかミドルウェアみたいなのは全然気にならないんだけど
BootstrapとかLaravelとかjQueryとかみたいな固有名をカタカナで書いてるの見るとなんか「うわっ」って思っちゃうんだよね
なんでだろ

39 ：
>>35

そうだよ。だって、本来のmiddlewareって、そういうもんじゃないもん。
Laravelが勝手に言ってる概念じゃん。

40 ：
Laravelがっていうよりもサーバーサイドプログラミング全般で使われる言葉じゃないか？
NodeのExpressでも同じ様にMiddlewareってあるし多分RoRにもDjangoってあるだろ

単にOSに対してのミドルウェアと違う様に見えるだけで相対的な意味ではやっぱミドルウェアだろ

41 ：
そんな言い分認めない。

42 ：
>>40
もっとまともな言い訳考えてこい

43 ：
だいたい、MVCどこ行ったんだよ。
うちのMVCでは手が足りないのでmiddlewareさんを助っ人に呼びましたってか？
そんなポンコツ、設計し直せ。

44 ：
あ、オレ、もしかして今核心ついた？
そういうことやってるからしょっちゅうでかい互換性のないアップデートかけてる？もしかして。

45 ：
結構大規模にやってるけどドメインロジックはPOPOのサービス層に書いてるしコントローラは薄く保てる

そもそもMVC2とかただのUIアーキテクチャじゃん
ある程度複雑になればそれぞれのレイヤ、特にMの中身も設計する必要があるのは当然でしょ

46 ：
>>22
＞>>12
＞だから比較対象になるダメじゃない例がないと考察のしようがないだろ
＞例を挙げろよ例を

これあったら誰か教えて

47 ：
どうせオレオレフレームワークが最強って言いたいだけなんだろうけどな

そういう奴に限ってユーザー認証用のパスワードをDBに平文で持つとかいう愚かな事やってる

48 ：
>>45
>ある程度複雑になればそれぞれのレイヤ、特にMの中身も設計する必要があるのは当然でしょ

おまえは本当に分かってないな。

複雑化してきた時の設計をユーザーに委ねてたらフレームワークの意味なくなるだろ。
そういう時の事まで考えて提示して初めてフレームワークなんだよ。
たとえば>>13みたいな事をさ、フレームワークとして提供すんの。
勿論、そのままやったら馬鹿だけどな。

CakePHPが流行ってた頃さ、ModelはDBにアクセスする物と誤解されて
それ以外が全部Controllerに書かれてファットコントローラーだらけになったのな。

で「CakeはDBにアクセスしないModel“も”作れるのに」って言い張ってたやつがいたけど、
根本的に、そういう設計が狂っちゃってんだよ。

49 ：
>>47

お前のレベルが低すぎる事だけは、その発言でよーくわかった。

50 ：
現にここまで理想的なモデルとしての具体例・対案が一切出てない件

51 ：
>>50

は？　オレ、前にヒント出しといたけど？

52 ：
まったく、>>50は馬鹿だなぁ。

53 ：
ID消すの忘れてますよ

54 ：
なんで消さなきゃいけないの？

55 ：
くだらない事考える暇あるならVue.jsなりReactなり習得してMVVMで作れば解決じゃん
なんか異論があるなら受け付けるけど

56 ：
もしかして、ただの連投を自演だと思ったとか？
本当にバカだなぁ。

57 ：
>>55

底抜けのバカが現れた。

58 ：
>>57
あなたのいう欠点を克服しているフレームワークは何？
それと比較してみたいんだが

59 ：
githubのスター獲得数が最高だから他のフレームワークと比べて
一番評価されているのでは

60 ：
みんなLaravelが優れていると思っているからgithubで最高評価もらってるし
大規模システムにも採用されているんだろう。

61 ：
おまえはPoEAA読み直してこい。ARは数あるパターンのひとつであって銀の弾丸ではない。データアクセスの抽象化が目的だ。
MVCに拘りすぎるのもやめろ。あれはステートフルなGUIアプリケーションの概念であってステートレスなウェブには合わない概念も多い。AndroidやiOSにはまだまた有用だが。
ソフトウェア構築の肝は疎結合だ。これが実現できるならオレオレ設計で全く問題ない。
フレームワークが担うのはHTTP入出力やデータアクセスなどどんなシステムでも利用する機能の共通化だけだ。ロジックが複雑化してきたときの助けにはならない。そこは自分とメンバーのスキルと規模によって良い方法を考えろ。

62 ：
バカが、レベルの低いフレームワークに引きずられて長文で語ってる。

63 ：
だったらフレームワークなんか使わずに全て自分で書けばいいだけやんw
オレオレフレームワークが最高なんだろ
このスレに常駐してる理由が分からんw

64 ：
バカ、逆ギレ。

65 ：
やっぱ、爆裂コントローラー生成機という見方は正しかったって事か。
使えんな、こんなもん。

66 ：
せっかく長文で書いてやったんだから反論頼むよ。おれこういう議論好き。
世の中しょぼいエンジニアしかいないから口が悪い奴でも楽しい話できるなら付き合うよ。

67 ：
ただの荒らしだよ
反論できるような知識もない

68 ：
フルスタックフレームワークはフルスタックエンジニアのためのフレームワーク

69 ：
連投して議論じゃなく勝利宣言しかできないキッズはキッズ向けの板に行った方がいいと思うんよね

70 ：
まぁあらしの課題感は間違ってないと思うよ。議論にはならないけど。
ファットコントローラは世間的にも話題になったしファットモデルも同じく。
自分はDBアクセスなしのPOPOオブジェクトをたくさん作るのが好きだけど、それは小規模チームだから。大規模になると破綻する。
一方でJavaのSeasarみたいに大規模チームでワークするフレームワーク作った人たちもいたし。

71 ：
>>66

んーとさ、前スレだったか、上の方だったかにさ、
「Symfonyに何も学ばなかったのか？」って書いたじゃん。

Symfonyは個々の要求をさばくのにActionを使っていて、
それぞれを別のActionに分けることでControllerが肥大するのを防いでいた。
>>13みたいなのを、フレームワークの仕組みとして提供していた。
（褒められるのはそのくらいだったように記憶しているけど）

よくあるダメなフレームワークの典型のもう一つが、
Viewは描画をする場所なので、ロジックを書いてはいけないとしているところ。
だから、View=テンプレートみたいなアホみたいなことをしてしまう。
実際には描画に関する分岐やループというものはあって、
そういうのをテンプレート内でやろうとすると、
デザイナが手を出せない代物になってしまって破綻する。
つまり、大規模になると破綻する。
Laravelにそういうところのケアがあるようにはとても見えない。

ActiveRecordのような実装もダメ。
前スレでも言ったけど、テーブルに結びつくORMはJOINが困難になるので
RDBという資産をまるで生かせなくなってくる。
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
とかキチガイが言っていたが、そういうことするからコードがゴミクズのようになるし、
ちょと複雑な処理をするとクソ遅くてメンテ不能になってくる。
流行りなんじゃなくて、それしか出来ないからそうしているだけ。

とにかく、どのフレームワークもRoRに引っ張られすぎ。

72 ：
>>71
それBladeテンプレートの仕様確認してから言ってる？

73 ：
それから、よくあり過ぎて頭いたくなってくるんだけどさ、

https://readouble.com/laravel/5.5/ja/validation.html

public function store(Request $request)
{
$validatedData = $request->validate([
'title' => 'required|unique:posts|max:255',
'body' => 'required',
]);

// ブログポストは有効
}

この、max:255　って単位はなんだ？
どっかでちゃんと分けてるんだよな？　よく読んでないから知らないけど。

言ってる意味、分かるか？

74 ：
>>72
してない。現段階ではする気も起きない。
既にTwigっていう優秀なテンプレートエンジンが存在するのに、
わざわざBladeとかいうわけのわからん独自テンプレートを持ち込んでくる神経が
そもそも理解できない。

75 ：
あとDBに関してはこれ
https://readouble.com/laravel/5.8/ja/database.html
https://readouble.com/laravel/5.8/ja/queries.html

76 ：
>>75

「これ」が、何？　論旨を言えないバカ？

77 ：
頭の固い老害ってとこだろうな
確認もせずにTwigが云々語っちゃう辺りはその典型

78 ：
>>77

ねぼけてんなぁ。Laravelでしか使われんBladeごときが、
Twig様に勝てるわけねーだろ。

79 ：
流石に検索系でよっぽど単純な操作をやる場合以外でORMなんてそう使わんだろ
挿入、更新、削除なら積極的に使った方がシンプルになるだろうけど

80 ：
>>79

だからさ、エロなんとかと別のクエリビルダと、使い分ける設計がクソだって言ってるの。
そしたら、ActiveRecordパターンなんかダメに決まってんだろ。
（エロなんとかがActiveRecordパターンなのかよくしらんけどさ）

もうちょっと、頭使って作れって話。

81 ：
こいつが作った超イケてるフレームワークがGitHubに出てくる日を待つかw

82 ：
別のクエリビルダの方は、SELECT結果はstdClassになっちゃいまぁす、とかさ。
そしたら、結果のオブジェクトになんかメソッド仕込むとかできねーだろ。
ActiveRecordはフォーマッタ仕込んだり
極端な話、オブジェクト自体にバリデーション埋め込むことだってできるけど、
stdClassじゃただデータ持ち運ぶ事しかできんじゃねぇか。

83 ：
Symfonyがいいって言うんならSymfony使ってればいいじゃん
別にそこを否定はせんよ

なんでわざわざ他所に喧嘩売りに来るのかその神経が分からん

84 ：
急に進んでたから面白い議論でも始まったかと思ったら低脳が湧いて釣られたやつらがいただけだった
みんなちゃんとNGしとけよ

85 ：
>>82
データをDBに書き込む時にはバリデーション必要だけど
既に保存されたデータを検索して表示する過程にバリデーション必要か？

86 ：
>>83

ボケナス、褒められるのはそこだけだったって言ってんだろ。
つかえるか、あんなポンコツ。

87 ：
>>85

フォーマッタはあったら便利だろ。

88 ：
先のことをさぁ、考えて、作るんだよ。

>>85くん。

89 ：
>>71
まずオレの意見から言うとSymfonyは素晴らしい。けど理想を追い求めすぎて複雑。Laravelはバランスが良くて小規模アプリは最高。ただしEloquentはクソ。Doctrine持って来い。

Laravel触ってみるといいよ。勘違いしてる部分も多そうだし。
Actionの部分はService Containerを調べて。
Viewの話はロジックというのは業務ロジックのことで、例えばこの会員はAランクなので付与率5%、それ以外は1%というような話でこれはViewじゃなくてモデルに書きましょうということだ。表示のための分岐はいくらでも書いて問題ないよ。
最近のARはJOINしてもうまくマッピングしてくれるようになってる。各ORMがN+1問題をどう解決してるかコード読め。Doctrineはコードがきれいだぞ。
クエリビルダとエロは別々のものじゃなくてビルダの上位レイヤがエロだ。普通はエロだけでよい。withとlazy loadの仕組みである程度速度のコントロールはできる。
RoRとLaravelが似てるのは否定しない。Symfonyは別の問題を解決しようとしてるから用途が違う。果物ナイフとノコギリを比べるようなもんだ。

90 ：
>>71
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
は確かGoogleが推奨しているコーディング方式だね。
GoogleのWEBサービスは全部このやり方で実装されている。

91 ：
>>73
Request生で使う奴はいないでしょ。
普通はフォームリクエスト使ってそっちで宣言する

92 ：
>>90
そりゃGoogleはGCP売りたいんだからそう言うだろ。RDBを使わないシステムをターゲットにしてるんだから。
RDB使ってそんなことしてたらクソプログラマ認定されるぞ。
ぐーぐるさまが言ってるからって盲目的になるのは感心しないな。

93 ：
アスペルガー特有の強い拘り

94 ：
JavaのSpringFrameworkのJPAや
PythonのDjango
Ruby on Rails
Laravel
Symfony
等々みんなActiveRecord方式採用しているってことは
それで十分システムを構築できているんでしょう。

95 ：
>>89
>Viewの話はロジックというのは業務ロジックのことで、
>例えばこの会員はAランクなので付与率5%、
>それ以外は1%というような話で
>これはViewじゃなくてモデルに書きましょうということだ。

それをやめろって言ってんだ、ボケ。
なんで還元率適用後の値についてまでモデルが面倒見なきゃいけないんだ。

それはおまえ、社長が「よしこのお客さんには10%値引きしろ」って言ったら、
従業員が「社長、それはいくらになるんですか？」って言ってるようなもんだぞ。
馬鹿なのか？

96 ：
>>91

おまえは何を言っているのだ？

97 ：
>>94
採用してないよ。JPAとSymfony/Doctrineは違う。もう一回調べて。

98 ：
>>92
大勢でアクセスされた際のJOIN高負荷問題がどのDBもまだ未解決だから
大規模だとJOIN使わない方式が推奨されてるってだけじゃないの？
PostgreSQLやMySQLやOracleとかでJOIN高負荷問題の対策チームが
個別に存在しているぐらいだし

99 ：
>>94

つくるだけなら、な。
で、更改のたびにプログラマがヘドロのようになってるはずだ。

100 ：
MariaDBはわからんけど


100〜のスレッドの続きを読む
MySQL4.0を追っかけるスレ
他所のCookieを読み込みたいのですが
【企画】CGIでＲＰＧつくーる
【緊急】腕に覚えのあるプログラマー来てくれ！！
＝＝＝　ＩＩＳ　＝＝＝
【PHP】1が必死にPHPを勉強するスレ
SQL自体を勉強したい
プログラム言語遍歴
コンテンツ言語『 Curl 』情報交換スレ
結局ＷＥＢの言語は何がいいんだ？
--------------------
docomo PRIME F-10C Part2
【実売】最強の中級ブックシェルフ【50万以下】
【日テレ日22時半】あなたの番です part21【原田知世・田中圭】
● mabinogi -マビノギ- ジャイアント6670人目 ●
【清水佐紀】お姉さんズFANスレpart166【嗣永桃子】
【三國志13】Part100 三国志13
【スパロボ】スーパーロボット大戦X_Ω737体目【スパクロ】
∞∞ 妊娠22週〜31週までの奥様 133 ∞∞
【】今日のドラえもんがヤバい [192973851]
N国党【8ヶ月目スタート】NHKから国民を守る党【ちだいの爆弾不発www】228
all car ?
【PSP】Fate/EXTRA総合 266スレ
法政大学野球部 Part120
【京楽】Pぱちんこ 劇場版 魔法少女まどか☆マギカ part16
【韓流】あの『クラスメイト』が新曲、『腹立ちまぎれに』を発表･･･正統派バラードに挑戦！[09/29]
Android用エミュレータについて語るスレ★39
東京マルイガスガン総合 211
【3DS】プロジェクトクロスゾーン総合 Part224
懐かしのビクトリアステーションを語ろう！
和道流柔術拳法はどこまでが空手なのか議論するスレ
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼