私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】Laravel【フレームワーク】 Part.2
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
まったく、>>50は馬鹿だなぁ。
くだらない事考える暇あるならVue.jsなりReactなり習得してMVVMで作れば解決じゃん
なんか異論があるなら受け付けるけど
なんか異論があるなら受け付けるけど
もしかして、ただの連投を自演だと思ったとか?
本当にバカだなぁ。
本当にバカだなぁ。
githubのスター獲得数が最高だから他のフレームワークと比べて
一番評価されているのでは
一番評価されているのでは
みんなLaravelが優れていると思っているからgithubで最高評価もらってるし
大規模システムにも採用されているんだろう。
大規模システムにも採用されているんだろう。
おまえはPoEAA読み直してこい。ARは数あるパターンのひとつであって銀の弾丸ではない。データアクセスの抽象化が目的だ。
MVCに拘りすぎるのもやめろ。あれはステートフルなGUIアプリケーションの概念であってステートレスなウェブには合わない概念も多い。AndroidやiOSにはまだまた有用だが。
ソフトウェア構築の肝は疎結合だ。これが実現できるならオレオレ設計で全く問題ない。
フレームワークが担うのはHTTP入出力やデータアクセスなどどんなシステムでも利用する機能の共通化だけだ。ロジックが複雑化してきたときの助けにはならない。そこは自分とメンバーのスキルと規模によって良い方法を考えろ。
MVCに拘りすぎるのもやめろ。あれはステートフルなGUIアプリケーションの概念であってステートレスなウェブには合わない概念も多い。AndroidやiOSにはまだまた有用だが。
ソフトウェア構築の肝は疎結合だ。これが実現できるならオレオレ設計で全く問題ない。
フレームワークが担うのはHTTP入出力やデータアクセスなどどんなシステムでも利用する機能の共通化だけだ。ロジックが複雑化してきたときの助けにはならない。そこは自分とメンバーのスキルと規模によって良い方法を考えろ。
バカが、レベルの低いフレームワークに引きずられて長文で語ってる。
だったらフレームワークなんか使わずに全て自分で書けばいいだけやんw
オレオレフレームワークが最高なんだろ
このスレに常駐してる理由が分からんw
オレオレフレームワークが最高なんだろ
このスレに常駐してる理由が分からんw
やっぱ、爆裂コントローラー生成機という見方は正しかったって事か。
使えんな、こんなもん。
使えんな、こんなもん。
せっかく長文で書いてやったんだから反論頼むよ。おれこういう議論好き。
世の中しょぼいエンジニアしかいないから口が悪い奴でも楽しい話できるなら付き合うよ。
世の中しょぼいエンジニアしかいないから口が悪い奴でも楽しい話できるなら付き合うよ。
フルスタックフレームワークはフルスタックエンジニアのためのフレームワーク
連投して議論じゃなく勝利宣言しかできないキッズはキッズ向けの板に行った方がいいと思うんよね
まぁあらしの課題感は間違ってないと思うよ。議論にはならないけど。
ファットコントローラは世間的にも話題になったしファットモデルも同じく。
自分はDBアクセスなしのPOPOオブジェクトをたくさん作るのが好きだけど、それは小規模チームだから。大規模になると破綻する。
一方でJavaのSeasarみたいに大規模チームでワークするフレームワーク作った人たちもいたし。
ファットコントローラは世間的にも話題になったしファットモデルも同じく。
自分はDBアクセスなしのPOPOオブジェクトをたくさん作るのが好きだけど、それは小規模チームだから。大規模になると破綻する。
一方でJavaのSeasarみたいに大規模チームでワークするフレームワーク作った人たちもいたし。
>>66
んーとさ、前スレだったか、上の方だったかにさ、
「Symfonyに何も学ばなかったのか?」って書いたじゃん。
Symfonyは個々の要求をさばくのにActionを使っていて、
それぞれを別のActionに分けることでControllerが肥大するのを防いでいた。
>>13みたいなのを、フレームワークの仕組みとして提供していた。
(褒められるのはそのくらいだったように記憶しているけど)
よくあるダメなフレームワークの典型のもう一つが、
Viewは描画をする場所なので、ロジックを書いてはいけないとしているところ。
だから、View=テンプレートみたいなアホみたいなことをしてしまう。
実際には描画に関する分岐やループというものはあって、
そういうのをテンプレート内でやろうとすると、
デザイナが手を出せない代物になってしまって破綻する。
つまり、大規模になると破綻する。
Laravelにそういうところのケアがあるようにはとても見えない。
ActiveRecordのような実装もダメ。
前スレでも言ったけど、テーブルに結びつくORMはJOINが困難になるので
RDBという資産をまるで生かせなくなってくる。
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
とかキチガイが言っていたが、そういうことするからコードがゴミクズのようになるし、
ちょと複雑な処理をするとクソ遅くてメンテ不能になってくる。
流行りなんじゃなくて、それしか出来ないからそうしているだけ。
とにかく、どのフレームワークもRoRに引っ張られすぎ。
んーとさ、前スレだったか、上の方だったかにさ、
「Symfonyに何も学ばなかったのか?」って書いたじゃん。
Symfonyは個々の要求をさばくのにActionを使っていて、
それぞれを別のActionに分けることでControllerが肥大するのを防いでいた。
>>13みたいなのを、フレームワークの仕組みとして提供していた。
(褒められるのはそのくらいだったように記憶しているけど)
よくあるダメなフレームワークの典型のもう一つが、
Viewは描画をする場所なので、ロジックを書いてはいけないとしているところ。
だから、View=テンプレートみたいなアホみたいなことをしてしまう。
実際には描画に関する分岐やループというものはあって、
そういうのをテンプレート内でやろうとすると、
デザイナが手を出せない代物になってしまって破綻する。
つまり、大規模になると破綻する。
Laravelにそういうところのケアがあるようにはとても見えない。
ActiveRecordのような実装もダメ。
前スレでも言ったけど、テーブルに結びつくORMはJOINが困難になるので
RDBという資産をまるで生かせなくなってくる。
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
とかキチガイが言っていたが、そういうことするからコードがゴミクズのようになるし、
ちょと複雑な処理をするとクソ遅くてメンテ不能になってくる。
流行りなんじゃなくて、それしか出来ないからそうしているだけ。
とにかく、どのフレームワークもRoRに引っ張られすぎ。
>>71
それBladeテンプレートの仕様確認してから言ってる?
それBladeテンプレートの仕様確認してから言ってる?
それから、よくあり過ぎて頭いたくなってくるんだけどさ、
http://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 って単位はなんだ?
どっかでちゃんと分けてるんだよな? よく読んでないから知らないけど。
言ってる意味、分かるか?
http://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 って単位はなんだ?
どっかでちゃんと分けてるんだよな? よく読んでないから知らないけど。
言ってる意味、分かるか?
>>72
してない。現段階ではする気も起きない。
既にTwigっていう優秀なテンプレートエンジンが存在するのに、
わざわざBladeとかいうわけのわからん独自テンプレートを持ち込んでくる神経が
そもそも理解できない。
してない。現段階ではする気も起きない。
既にTwigっていう優秀なテンプレートエンジンが存在するのに、
わざわざBladeとかいうわけのわからん独自テンプレートを持ち込んでくる神経が
そもそも理解できない。
頭の固い老害ってとこだろうな
確認もせずにTwigが云々語っちゃう辺りはその典型
確認もせずにTwigが云々語っちゃう辺りはその典型
流石に検索系でよっぽど単純な操作をやる場合以外でORMなんてそう使わんだろ
挿入、更新、削除なら積極的に使った方がシンプルになるだろうけど
挿入、更新、削除なら積極的に使った方がシンプルになるだろうけど
>>79
だからさ、エロなんとかと別のクエリビルダと、使い分ける設計がクソだって言ってるの。
そしたら、ActiveRecordパターンなんかダメに決まってんだろ。
(エロなんとかがActiveRecordパターンなのかよくしらんけどさ)
もうちょっと、頭使って作れって話。
だからさ、エロなんとかと別のクエリビルダと、使い分ける設計がクソだって言ってるの。
そしたら、ActiveRecordパターンなんかダメに決まってんだろ。
(エロなんとかがActiveRecordパターンなのかよくしらんけどさ)
もうちょっと、頭使って作れって話。
こいつが作った超イケてるフレームワークがGitHubに出てくる日を待つかw
別のクエリビルダの方は、SELECT結果はstdClassになっちゃいまぁす、とかさ。
そしたら、結果のオブジェクトになんかメソッド仕込むとかできねーだろ。
ActiveRecordはフォーマッタ仕込んだり
極端な話、オブジェクト自体にバリデーション埋め込むことだってできるけど、
stdClassじゃただデータ持ち運ぶ事しかできんじゃねぇか。
そしたら、結果のオブジェクトになんかメソッド仕込むとかできねーだろ。
ActiveRecordはフォーマッタ仕込んだり
極端な話、オブジェクト自体にバリデーション埋め込むことだってできるけど、
stdClassじゃただデータ持ち運ぶ事しかできんじゃねぇか。
Symfonyがいいって言うんならSymfony使ってればいいじゃん
別にそこを否定はせんよ
なんでわざわざ他所に喧嘩売りに来るのかその神経が分からん
別にそこを否定はせんよ
なんでわざわざ他所に喧嘩売りに来るのかその神経が分からん
急に進んでたから面白い議論でも始まったかと思ったら低脳が湧いて釣られたやつらがいただけだった
みんなちゃんとNGしとけよ
みんなちゃんとNGしとけよ
>>90
そりゃGoogleはGCP売りたいんだからそう言うだろ。RDBを使わないシステムをターゲットにしてるんだから。
RDB使ってそんなことしてたらクソプログラマ認定されるぞ。
ぐーぐるさまが言ってるからって盲目的になるのは感心しないな。
そりゃGoogleはGCP売りたいんだからそう言うだろ。RDBを使わないシステムをターゲットにしてるんだから。
RDB使ってそんなことしてたらクソプログラマ認定されるぞ。
ぐーぐるさまが言ってるからって盲目的になるのは感心しないな。
JavaのSpringFrameworkのJPAや
PythonのDjango
Ruby on Rails
Laravel
Symfony
等々みんなActiveRecord方式採用しているってことは
それで十分システムを構築できているんでしょう。
PythonのDjango
Ruby on Rails
Laravel
Symfony
等々みんなActiveRecord方式採用しているってことは
それで十分システムを構築できているんでしょう。
>>89
>Viewの話はロジックというのは業務ロジックのことで、
>例えばこの会員はAランクなので付与率5%、
>それ以外は1%というような話で
>これはViewじゃなくてモデルに書きましょうということだ。
それをやめろって言ってんだ、ボケ。
なんで還元率適用後の値についてまでモデルが面倒見なきゃいけないんだ。
それはおまえ、社長が「よしこのお客さんには10%値引きしろ」って言ったら、
従業員が「社長、それはいくらになるんですか?」って言ってるようなもんだぞ。
馬鹿なのか?
>Viewの話はロジックというのは業務ロジックのことで、
>例えばこの会員はAランクなので付与率5%、
>それ以外は1%というような話で
>これはViewじゃなくてモデルに書きましょうということだ。
それをやめろって言ってんだ、ボケ。
なんで還元率適用後の値についてまでモデルが面倒見なきゃいけないんだ。
それはおまえ、社長が「よしこのお客さんには10%値引きしろ」って言ったら、
従業員が「社長、それはいくらになるんですか?」って言ってるようなもんだぞ。
馬鹿なのか?
>>92
大勢でアクセスされた際のJOIN高負荷問題がどのDBもまだ未解決だから
大規模だとJOIN使わない方式が推奨されてるってだけじゃないの?
PostgreSQLやMySQLやOracleとかでJOIN高負荷問題の対策チームが
個別に存在しているぐらいだし
大勢でアクセスされた際のJOIN高負荷問題がどのDBもまだ未解決だから
大規模だとJOIN使わない方式が推奨されてるってだけじゃないの?
PostgreSQLやMySQLやOracleとかでJOIN高負荷問題の対策チームが
個別に存在しているぐらいだし
みんなの評価 :
類似してるかもしれないスレッド
- 【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
トップメニューへ / →のくす牧場書庫について