[過去ﾛｸﾞ] 【PHP】Laravel【フレームワーク】 Part.2 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1: 2019/04/28(日)11:07 ID:2Xx6RWTL(1) AAS
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
外部ﾘﾝｸ:laravel.com
git
外部ﾘﾝｸ:github.com
動画チュートリアル(英語)
外部ﾘﾝｸ:laracasts.com
日本語
外部ﾘﾝｸ:laravel.jp
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
外部ﾘﾝｸ:www.amazon.co.jp
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
外部ﾘﾝｸ:www.amazon.co.jp
※前スレ
【PHP】Laravel【フレームワーク】
2chｽﾚ:php
2: 2019/04/28(日)12:09 ID:??? AAS
魔法少女ララベル
外部ﾘﾝｸ:www.nicovideo.jp
3: 2019/04/29(月)02:00 ID:yaiOsc/q(1) AAS
createを使って更新するのとモデルをsaveして更新するのどう違うんやろ。
createの時だけguardedを設定しないといけないとかそもそも複数代入ってどういうことやねん。もーなんじゃいな
4(1): 2019/04/29(月)11:23 ID:??? AAS
あーのさー、Laravelってホントに便利なん？
ちらっと見てみた感じ、なんか、RoRとかCodeIgniterとかCakeとかがおかしてる間違いをそのまま引きずってる気がするんだけど？
これ、簡単なWEBアプリならRoRと同じでお手軽かもしんないんだけど
アプリが複雑になってくるとすぐ死なないか？
5: 再投稿は甘えおじさん 2019/04/29(月)11:44 ID:??? AAS
再投稿は甘え
6: 2019/04/29(月)11:54 ID:??? AAS
前スレで叩かれたからって再レスかよｗｗ
7(1): 2019/04/29(月)11:55 ID:??? AAS
6 名前：デフォルトの名無しさん[sage] 投稿日：2019/04/29(月) 02:19:44.72 ID:l/Mc2djO
Laravelとそれ以前のフレームワークの違いってLaravelはフロントエンド側のフレームワークとの連携機構がしっかりしてるから
PHP側のControllerはリクエストに応じてDBの読み書きさえやってればあとの制御はフロント側任せにできるとこだと思うんよね
2chｽﾚ:tech
8: 2019/04/29(月)12:01 ID:??? AAS
Laravel-Mixは便利
9: 2019/04/29(月)13:01 ID:??? AAS
>>7
だから、アプリが複雑になるとどうせフォットコントローラになるんだろ
って言ってるんだが。
RoRとかCakeとかといっしょで爆裂Controller生成機じゃないか？
いつになったらこれじゃダメだって気づくんだ？
10: 2019/04/29(月)13:02 ID:??? AAS
フォットコントローラｗｗｗｗｗｗｗｗ
ファットだろｗｗｗｗ
11(3): 2019/04/29(月)13:20 ID:??? AAS
複雑化した時に肥大化しないControllerモデルがあるのか？
まぁ表示制御をフロントに任せる限りはバックエンド側はシンプル、フロントエンドは規模なりのサイズになるわけだけど
12(2): 2019/04/29(月)13:26 ID:??? AAS
>>11
前スレでも言ったけどその時点でLaravelはダメなんだよ。
というかRoR、Cake、Laravel、Symfonyこれらみんなダメ
13(2): 2019/04/29(月)13:38 ID:??? AAS
細かい処理はコントローラーから別ファイルの関数呼び出すだけにしてるから
複雑な処理のあるコントローラーも20行ぐらいで収まっているぞ、俺の場合
14: 2019/04/29(月)13:40 ID:??? AAS
実際ガチのWEBシステムをLaravelで構築しているときって
どういう作りになってるのか見てみたい。
誰かオープンソースでgithubに上げてないのかな
15: 2019/04/29(月)13:42 ID:??? AAS
フロントエンドフレームワーク利用手順
・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: 2019/04/29(月)13:44 ID:??? AAS
Laravelをガチで有意義に使うならVueかReactの習得は必須だと思うんよね
バックエンド側でやること殆どないからイチイチフロントとバックで分業するほどでもないと思うけど
17: 2019/04/29(月)15:07 ID:??? AAS
今後もVueが活発になったら
laravelはAPIのみって感じが主流になりそうだね
18: 2019/04/29(月)15:11 ID:??? AAS
ガッツリ組むならReactの方が後の再利用性はいいと思う
19: 2019/04/29(月)15:12 ID:??? AAS
うちはjQueryとBootstrapでゴリゴリだわ
20: 2019/04/29(月)15:26 ID:??? AAS
正直脱Bootstrapもやってみたいけど他のCSSフレームワークで何がいいかイマイチ分からんのよね
21(1): 2019/04/29(月)15:38 ID:EIk3HTnc(1/4) AAS
>>11
よー分からん。一番でっかくなるのはモデルじゃないんか？
素人だから複雑なシステムはわからんけどコントローラが痩せたらモデルがでっかくなりつつある
22(2): 2019/04/29(月)15:42 ID:??? AAS
>>12
だから比較対象になるダメじゃない例がないと考察のしようがないだろ
例を挙げろよ例を
23: 2019/04/29(月)15:47 ID:??? AAS
>>22
自演乙
24: 2019/04/29(月)15:56 ID:??? AAS
自演も何も理想的なモデルって一体何なわけ？
25(1): 2019/04/29(月)15:58 ID:??? AAS
>>21
書く量が変わるわけではないでしょ。
どこに書くかが変わるだけだから、どこかが減ればどこかが増えるのは仕方ない。
26: 2019/04/29(月)16:42 ID:??? AAS
BootstrapをベースにscopedにSCSS書けるのが便利過ぎて他に移行する気が起きない
27: 2019/04/29(月)17:18 ID:??? AAS
Laravelはもはやスタンダードでしょ
28: 2019/04/29(月)17:28 ID:EIk3HTnc(2/4) AAS
>>25
なるほど。大事なのは後で読んだ時に分かり易いことでそれでいいんだな。
29(1): 2019/04/29(月)19:10 ID:??? AAS
Controller肥大化させん為にMiddlewareとかViewComposerとか幾つか回避策もあるんだけどね
30: 2019/04/29(月)21:41 ID:JcU2QOSZ(1) AAS
>>29
そういう、わけのわからん独自のアーキテクチャで何とかしようとするのやめれ。
31: 2019/04/29(月)21:50 ID:??? AAS
middlewareにするなら汎用化してくれないとロジックが取っ散らかるので慎重に
32: 2019/04/29(月)22:23 ID:??? AAS
四の五の言わずに表示系は全部フロントフレームワークにすりゃいいんだよ
33: 2019/04/29(月)23:02 ID:EIk3HTnc(3/4) AAS
>>11
よー分からん。一番でっかくなるのはモデルじゃないんか？
素人だから複雑なシステムはわからんけどコントローラが痩せたらモデルがでっかくなりつつある
34: 2019/04/29(月)23:02 ID:EIk3HTnc(4/4) AAS
ミスった
35(1): 2019/04/29(月)23:06 ID:??? AAS
ミドルウェアが独自のアーキテクチャとかマジで言ってるんです？
36: 2019/04/29(月)23:22 ID:??? AAS
なんか無知を晒してるヤツ何人か居るがまぁ同一人物なんだろうね
37: 2019/04/29(月)23:36 ID:??? AAS
たとえララベル使わなくてもコードは肥大化するじゃん
38: 2019/04/29(月)23:44 ID:??? AAS
アーキテクチャとかフレームワークとかミドルウェアみたいなのは全然気にならないんだけど
BootstrapとかLaravelとかjQueryとかみたいな固有名をカタカナで書いてるの見るとなんか「うわっ」って思っちゃうんだよね
なんでだろ
39: 2019/04/30(火)01:33 ID:U8oZvJd3(1/43) AAS
>>35
そうだよ。だって、本来のmiddlewareって、そういうもんじゃないもん。
Laravelが勝手に言ってる概念じゃん。
40(1): 2019/04/30(火)01:47 ID:??? AAS
Laravelがっていうよりもサーバーサイドプログラミング全般で使われる言葉じゃないか？
NodeのExpressでも同じ様にMiddlewareってあるし多分RoRにもDjangoってあるだろ
単にOSに対してのミドルウェアと違う様に見えるだけで相対的な意味ではやっぱミドルウェアだろ
41: 2019/04/30(火)01:55 ID:U8oZvJd3(2/43) AAS
そんな言い分認めない。
42: 2019/04/30(火)01:58 ID:??? AAS
>>40
もっとまともな言い訳考えてこい
43: 2019/04/30(火)01:59 ID:U8oZvJd3(3/43) AAS
だいたい、MVCどこ行ったんだよ。
うちのMVCでは手が足りないのでmiddlewareさんを助っ人に呼びましたってか？
そんなポンコツ、設計し直せ。
44: 2019/04/30(火)02:04 ID:U8oZvJd3(4/43) AAS
あ、オレ、もしかして今核心ついた？
そういうことやってるからしょっちゅうでかい互換性のないアップデートかけてる？もしかして。
45(1): 2019/04/30(火)03:38 ID:??? AAS
結構大規模にやってるけどドメインロジックはPOPOのサービス層に書いてるしコントローラは薄く保てる
そもそもMVC2とかただのUIアーキテクチャじゃん
ある程度複雑になればそれぞれのレイヤ、特にMの中身も設計する必要があるのは当然でしょ
46: 2019/04/30(火)03:55 ID:??? AAS
>>22
＞>>12
＞だから比較対象になるダメじゃない例がないと考察のしようがないだろ
＞例を挙げろよ例を
これあったら誰か教えて
47(1): 2019/04/30(火)06:39 ID:??? AAS
どうせオレオレフレームワークが最強って言いたいだけなんだろうけどな
そういう奴に限ってユーザー認証用のパスワードをDBに平文で持つとかいう愚かな事やってる
48: 2019/04/30(火)08:25 ID:U8oZvJd3(5/43) AAS
>>45
>ある程度複雑になればそれぞれのレイヤ、特にMの中身も設計する必要があるのは当然でしょ
おまえは本当に分かってないな。
複雑化してきた時の設計をユーザーに委ねてたらフレームワークの意味なくなるだろ。
そういう時の事まで考えて提示して初めてフレームワークなんだよ。
たとえば>>13みたいな事をさ、フレームワークとして提供すんの。
勿論、そのままやったら馬鹿だけどな。
CakePHPが流行ってた頃さ、ModelはDBにアクセスする物と誤解されて
それ以外が全部Controllerに書かれてファットコントローラーだらけになったのな。
で「CakeはDBにアクセスしないModel“も”作れるのに」って言い張ってたやつがいたけど、
根本的に、そういう設計が狂っちゃってんだよ。
49: 2019/04/30(火)08:26 ID:U8oZvJd3(6/43) AAS
>>47
お前のレベルが低すぎる事だけは、その発言でよーくわかった。
50(2): 2019/04/30(火)09:33 ID:??? AAS
現にここまで理想的なモデルとしての具体例・対案が一切出てない件
51: 2019/04/30(火)09:39 ID:U8oZvJd3(7/43) AAS
>>50
は？ オレ、前にヒント出しといたけど？
52: 2019/04/30(火)09:40 ID:U8oZvJd3(8/43) AAS
まったく、>>50は馬鹿だなぁ。
53: 2019/04/30(火)09:46 ID:??? AAS
ID消すの忘れてますよ
54: 2019/04/30(火)09:59 ID:U8oZvJd3(9/43) AAS
なんで消さなきゃいけないの？
55(1): 2019/04/30(火)10:00 ID:??? AAS
くだらない事考える暇あるならVue.jsなりReactなり習得してMVVMで作れば解決じゃん
なんか異論があるなら受け付けるけど
56: 2019/04/30(火)10:00 ID:U8oZvJd3(10/43) AAS
もしかして、ただの連投を自演だと思ったとか？
本当にバカだなぁ。
57(1): 2019/04/30(火)10:02 ID:U8oZvJd3(11/43) AAS
>>55
底抜けのバカが現れた。
58: 2019/04/30(火)10:09 ID:??? AAS
>>57
あなたのいう欠点を克服しているフレームワークは何？
それと比較してみたいんだが
59: 2019/04/30(火)10:11 ID:??? AAS
githubのスター獲得数が最高だから他のフレームワークと比べて
一番評価されているのでは
60: 2019/04/30(火)10:25 ID:??? AAS
みんなLaravelが優れていると思っているからgithubで最高評価もらってるし
大規模システムにも採用されているんだろう。
61(6): 2019/04/30(火)10:45 ID:??? AAS
おまえはPoEAA読み直してこい。ARは数あるパターンのひとつであって銀の弾丸ではない。データアクセスの抽象化が目的だ。
MVCに拘りすぎるのもやめろ。あれはステートフルなGUIアプリケーションの概念であってステートレスなウェブには合わない概念も多い。AndroidやiOSにはまだまた有用だが。
ソフトウェア構築の肝は疎結合だ。これが実現できるならオレオレ設計で全く問題ない。
フレームワークが担うのはHTTP入出力やデータアクセスなどどんなシステムでも利用する機能の共通化だけだ。ロジックが複雑化してきたときの助けにはならない。そこは自分とメンバーのスキルと規模によって良い方法を考えろ。
62: 2019/04/30(火)10:52 ID:U8oZvJd3(12/43) AAS
バカが、レベルの低いフレームワークに引きずられて長文で語ってる。
63: 2019/04/30(火)11:02 ID:??? AAS
だったらフレームワークなんか使わずに全て自分で書けばいいだけやんw
オレオレフレームワークが最高なんだろ
このスレに常駐してる理由が分からんw
64: 2019/04/30(火)11:05 ID:U8oZvJd3(13/43) AAS
バカ、逆ギレ。
65: 2019/04/30(火)11:06 ID:U8oZvJd3(14/43) AAS
やっぱ、爆裂コントローラー生成機という見方は正しかったって事か。
使えんな、こんなもん。
66(1): 61 2019/04/30(火)11:11 ID:??? AAS
せっかく長文で書いてやったんだから反論頼むよ。おれこういう議論好き。
世の中しょぼいエンジニアしかいないから口が悪い奴でも楽しい話できるなら付き合うよ。
67: 2019/04/30(火)11:17 ID:??? AAS
ただの荒らしだよ
反論できるような知識もない
68: 2019/04/30(火)11:21 ID:??? AAS
フルスタックフレームワークはフルスタックエンジニアのためのフレームワーク
69: 2019/04/30(火)11:27 ID:??? AAS
連投して議論じゃなく勝利宣言しかできないキッズはキッズ向けの板に行った方がいいと思うんよね
70: 61 2019/04/30(火)11:37 ID:??? AAS
まぁあらしの課題感は間違ってないと思うよ。議論にはならないけど。
ファットコントローラは世間的にも話題になったしファットモデルも同じく。
自分はDBアクセスなしのPOPOオブジェクトをたくさん作るのが好きだけど、それは小規模チームだから。大規模になると破綻する。
一方でJavaのSeasarみたいに大規模チームでワークするフレームワーク作った人たちもいたし。
71(3): 2019/04/30(火)11:41 ID:U8oZvJd3(15/43) AAS
>>66
んーとさ、前スレだったか、上の方だったかにさ、
「Symfonyに何も学ばなかったのか？」って書いたじゃん。
Symfonyは個々の要求をさばくのにActionを使っていて、
それぞれを別のActionに分けることでControllerが肥大するのを防いでいた。
>>13みたいなのを、フレームワークの仕組みとして提供していた。
（褒められるのはそのくらいだったように記憶しているけど）
よくあるダメなフレームワークの典型のもう一つが、
Viewは描画をする場所なので、ロジックを書いてはいけないとしているところ。
だから、View=テンプレートみたいなアホみたいなことをしてしまう。
実際には描画に関する分岐やループというものはあって、
そういうのをテンプレート内でやろうとすると、
デザイナが手を出せない代物になってしまって破綻する。
つまり、大規模になると破綻する。
Laravelにそういうところのケアがあるようにはとても見えない。
ActiveRecordのような実装もダメ。
前スレでも言ったけど、テーブルに結びつくORMはJOINが困難になるので
RDBという資産をまるで生かせなくなってくる。
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
とかキチガイが言っていたが、そういうことするからコードがゴミクズのようになるし、
ちょと複雑な処理をするとクソ遅くてメンテ不能になってくる。
流行りなんじゃなくて、それしか出来ないからそうしているだけ。
とにかく、どのフレームワークもRoRに引っ張られすぎ。
72(1): 2019/04/30(火)11:44 ID:??? AAS
>>71
それBladeテンプレートの仕様確認してから言ってる？
73(2): 2019/04/30(火)11:45 ID:U8oZvJd3(16/43) AAS
それから、よくあり過ぎて頭いたくなってくるんだけどさ、
外部ﾘﾝｸ[html]:readouble.com
public function store(Request $request)
{
$validatedData = $request->validate([
'title' => 'required|unique:posts|max:255',
'body' => 'required',
]);
// ブログポストは有効
}
この、max:255 って単位はなんだ？
どっかでちゃんと分けてるんだよな？ よく読んでないから知らないけど。
言ってる意味、分かるか？
74: 2019/04/30(火)11:46 ID:U8oZvJd3(17/43) AAS
>>72
してない。現段階ではする気も起きない。
既にTwigっていう優秀なテンプレートエンジンが存在するのに、
わざわざBladeとかいうわけのわからん独自テンプレートを持ち込んでくる神経が
そもそも理解できない。
75(1): 2019/04/30(火)11:47 ID:??? AAS
あとDBに関してはこれ
外部ﾘﾝｸ[html]:readouble.com
外部ﾘﾝｸ[html]:readouble.com
76: 2019/04/30(火)11:49 ID:U8oZvJd3(18/43) AAS
>>75
「これ」が、何？ 論旨を言えないバカ？
77(1): 2019/04/30(火)11:55 ID:??? AAS
頭の固い老害ってとこだろうな
確認もせずにTwigが云々語っちゃう辺りはその典型
78: 2019/04/30(火)11:58 ID:U8oZvJd3(19/43) AAS
>>77
ねぼけてんなぁ。Laravelでしか使われんBladeごときが、
Twig様に勝てるわけねーだろ。
79(1): 2019/04/30(火)12:00 ID:??? AAS
流石に検索系でよっぽど単純な操作をやる場合以外でORMなんてそう使わんだろ
挿入、更新、削除なら積極的に使った方がシンプルになるだろうけど
80: 2019/04/30(火)12:03 ID:U8oZvJd3(20/43) AAS
>>79
だからさ、エロなんとかと別のクエリビルダと、使い分ける設計がクソだって言ってるの。
そしたら、ActiveRecordパターンなんかダメに決まってんだろ。
（エロなんとかがActiveRecordパターンなのかよくしらんけどさ）
もうちょっと、頭使って作れって話。
81: 2019/04/30(火)12:06 ID:??? AAS
こいつが作った超イケてるフレームワークがGitHubに出てくる日を待つかw
82(2): 2019/04/30(火)12:07 ID:U8oZvJd3(21/43) AAS
別のクエリビルダの方は、SELECT結果はstdClassになっちゃいまぁす、とかさ。
そしたら、結果のオブジェクトになんかメソッド仕込むとかできねーだろ。
ActiveRecordはフォーマッタ仕込んだり
極端な話、オブジェクト自体にバリデーション埋め込むことだってできるけど、
stdClassじゃただデータ持ち運ぶ事しかできんじゃねぇか。
83(1): 2019/04/30(火)12:07 ID:??? AAS
Symfonyがいいって言うんならSymfony使ってればいいじゃん
別にそこを否定はせんよ
なんでわざわざ他所に喧嘩売りに来るのかその神経が分からん
84: 2019/04/30(火)12:08 ID:??? AAS
急に進んでたから面白い議論でも始まったかと思ったら低脳が湧いて釣られたやつらがいただけだった
みんなちゃんとNGしとけよ
85(3): 2019/04/30(火)12:10 ID:??? AAS
>>82
データをDBに書き込む時にはバリデーション必要だけど
既に保存されたデータを検索して表示する過程にバリデーション必要か？
86: 2019/04/30(火)12:18 ID:U8oZvJd3(22/43) AAS
>>83
ボケナス、褒められるのはそこだけだったって言ってんだろ。
つかえるか、あんなポンコツ。
87(1): 2019/04/30(火)12:18 ID:U8oZvJd3(23/43) AAS
>>85
フォーマッタはあったら便利だろ。
88(1): 2019/04/30(火)12:19 ID:U8oZvJd3(24/43) AAS
先のことをさぁ、考えて、作るんだよ。
>>85くん。
89(2): 61 2019/04/30(火)12:19 ID:??? AAS
>>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(1): 2019/04/30(火)12:25 ID:??? AAS
>>71
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
は確かGoogleが推奨しているコーディング方式だね。
GoogleのWEBサービスは全部このやり方で実装されている。
91(1): 2019/04/30(火)12:26 ID:??? AAS
>>73
Request生で使う奴はいないでしょ。
普通はフォームリクエスト使ってそっちで宣言する
92(1): 2019/04/30(火)12:28 ID:??? AAS
>>90
そりゃGoogleはGCP売りたいんだからそう言うだろ。RDBを使わないシステムをターゲットにしてるんだから。
RDB使ってそんなことしてたらクソプログラマ認定されるぞ。
ぐーぐるさまが言ってるからって盲目的になるのは感心しないな。
93: 2019/04/30(火)12:28 ID:??? AAS
アスペルガー特有の強い拘り
94(2): 2019/04/30(火)12:28 ID:??? AAS
JavaのSpringFrameworkのJPAや
PythonのDjango
Ruby on Rails
Laravel
Symfony
等々みんなActiveRecord方式採用しているってことは
それで十分システムを構築できているんでしょう。
95(1): 2019/04/30(火)12:29 ID:U8oZvJd3(25/43) AAS
>>89
>Viewの話はロジックというのは業務ロジックのことで、
>例えばこの会員はAランクなので付与率5%、
>それ以外は1%というような話で
>これはViewじゃなくてモデルに書きましょうということだ。
それをやめろって言ってんだ、ボケ。
なんで還元率適用後の値についてまでモデルが面倒見なきゃいけないんだ。
それはおまえ、社長が「よしこのお客さんには10%値引きしろ」って言ったら、
従業員が「社長、それはいくらになるんですか？」って言ってるようなもんだぞ。
馬鹿なのか？
96: 2019/04/30(火)12:30 ID:U8oZvJd3(26/43) AAS
>>91
おまえは何を言っているのだ？
97(1): 61 2019/04/30(火)12:31 ID:??? AAS
>>94
採用してないよ。JPAとSymfony/Doctrineは違う。もう一回調べて。
98(2): 2019/04/30(火)12:31 ID:??? AAS
>>92
大勢でアクセスされた際のJOIN高負荷問題がどのDBもまだ未解決だから
大規模だとJOIN使わない方式が推奨されてるってだけじゃないの？
PostgreSQLやMySQLやOracleとかでJOIN高負荷問題の対策チームが
個別に存在しているぐらいだし
99: 2019/04/30(火)12:32 ID:U8oZvJd3(27/43) AAS
>>94
つくるだけなら、な。
で、更改のたびにプログラマがヘドロのようになってるはずだ。
100: 2019/04/30(火)12:32 ID:??? AAS
MariaDBはわからんけど
101(1): 2019/04/30(火)12:34 ID:U8oZvJd3(28/43) AAS
>>89
>表示のための分岐はいくらでも書いて問題ないよ。
それもやめろっって何回言わせんだ。
デザイナが触れなくなるだろーが。
102(1): 61 2019/04/30(火)12:34 ID:??? AAS
>>95
ん？おまえは還元率の計算をViewでやってるの？
ECサイトでポイントを表示するケースって、カートとか確認画面とかメルマガでDM送るときにこの商品を買ったら50ポイントです！とかあるけど、全部のビューに書いてる？変更するときどうすんの。
103(1): 2019/04/30(火)12:35 ID:??? AAS
>>97
JPAはOracleのJava Dayイベントで
ActiveRecord方式ってOracleの中の人が言ってるぞ
104: 2019/04/30(火)12:35 ID:??? AAS
>>98
経験上大量レコードからJOINで大幅にレコード件数減らせるんなら減らした方が低負荷になるはずだけどなぁ
間違ってたらスマン
105(1): 2019/04/30(火)12:39 ID:??? AAS
>>101
いやデザイナーに実コード触らせるとかやめろよ。そんなやり方
デザイナーから上がってきたhtmlはコーダーが実環境にマージ・適用した方が全体でみて低リスクだし低コストになる
106(2): 2019/04/30(火)12:39 ID:??? AAS
>>98
なんで世の中JOINが遅いことになってるんだろうな。最近のARしか知らないプログラマはほんと軟弱だわ。
JOINが遅いのは設定と設計とクエリが悪いの。その対策チームはJOINを無くすために存在してるんじゃなくて、設計とクエリを見直してパラメータを調整して速いJOINにするために存在してるの。対策した後もJOINを使うの。
107(2): 2019/04/30(火)12:41 ID:U8oZvJd3(29/43) AAS
>>102
>87
>>85
>フォーマッタはあったら便利だろ。
>88
>先のことをさぁ、考えて、作るんだよ。
>>85くん。
加えて、Twigには、FilterとFunctionという便利なものもある。
おまえは、石器時代の人間か？
108(1): 2019/04/30(火)12:43 ID:U8oZvJd3(30/43) AAS
>>105
おまえのアプリは作ったら作ったまんまか？
おまえ、サーバ側の改修やってるときに、
デザイナが書いたHTMLやCSSの面倒見たいか？
物好きだなぁ…。
109(1): 2019/04/30(火)12:43 ID:??? AAS
>>103
JPA自体はエンティテイにデータアクセスの機能は持たせない。レコードと1対1の構造はARっぽいが同じではない。
拡張のActiveJPAとかいうのと混同してるのでは？
110(1): 2019/04/30(火)12:44 ID:??? AAS
>>106
いや違う。複数からアクセスされたときに単純なクエリにかかわらず
JOINが高負荷になってしまう問題が存在していて
それを解決するために各チームが存在している。
解決したソースコードを提供した人には賞金が授与されるけど
未だ誰もこれを解決できるソースを提供できた人はいない
111(1): 2019/04/30(火)12:44 ID:??? AAS
>>107
でも>>82読んだ限りだとARにフォーマッタ仕込みたいんだろ？
Twigはテンプレートエンジンの方じゃんなんでごっちゃになってるの？
112(1): 2019/04/30(火)12:45 ID:U8oZvJd3(31/43) AAS
>>106
それは、下手くそなバカがJOINするからだ。
アホが書いたくそぐっちゃぐちゃのSQLを1/3に減らしたら
実行速度が1/10になりましたとか、普通にあるだろ。
あいつらは実行計画の見方もしらない。
JOIN前にSELECTで絞りまくったほうが速いとすら思っている。
113(1): 2019/04/30(火)12:45 ID:??? AAS
>>108
変に分からんヤツに荒らされて狂うくらいなら自分でやった方がいいに決まってるだろ
114(1): 2019/04/30(火)12:45 ID:??? AAS
>>109
Oracleの中の人が言ってるんだから混同してないでしょ。
もしくは今後実装予定の機能をポロっと言ってしまった可能性もあるけど
115(1): 61 2019/04/30(火)12:46 ID:??? AAS
>>107
FiltetとFunctionはだいたいどのテンプレートエンジンにもあるが、あれはヘルパであってロジックの置き場じゃないぞ。
116: 2019/04/30(火)12:46 ID:U8oZvJd3(32/43) AAS
>>111
「たい」んじゃなくて、仕込「める」と言っているんだ。
OOPというのはそういうものだ。
117(1): 2019/04/30(火)12:47 ID:??? AAS
>>114
いいからググれ。JPAの仕様とActiveJPAの仕様を読んでこい。違いがわかるから。
118: 2019/04/30(火)12:48 ID:U8oZvJd3(33/43) AAS
>>115
寝ぼけ過ぎだ。
お前が言っていた
>表示のための分岐はいくらでも書いて問題ない
場所、
それが、その場所だ。いい加減に気づけ。
119: 2019/04/30(火)12:48 ID:??? AAS
>>110
うーん皆の話に齟齬があるみたいだからその複数アクセスの規模を明示して？
多分秒間10や20くらいじゃそうならないよね？
120(2): 2019/04/30(火)12:48 ID:??? AAS
>>112
それはJOINじゃなくてクエリの書き方の問題でしょ。
ここで言われてる複数アクセス時のJOIN高負荷は賞金がかけられてるやつだから
DB本体のコーディングの問題。
121: 2019/04/30(火)12:50 ID:U8oZvJd3(34/43) AAS
>>113
まったく、だからお前のやっている仕事はスケールしないんだよ。
連投禁止かかりはじめたから、しばらくポイント貯めるぞ。
122: 2019/04/30(火)12:50 ID:??? AAS
Java Dayに参加したことあるけど確かにOracleはJPAを
ActiveRecord方式と言ってたな。
123(1): 2019/04/30(火)12:53 ID:??? AAS
>>120
何言ってんのか意味不明。JOINのアルゴリズムはほぼ確立されていて、データ量が膨大であれインデックスがメモリに乗ってCPUに余裕があればどんなに大量のアクセスがあっても理論上は遅くならない。Btreeの仕組みとインデックスの用途、実行計画について調べてこい。
124: 2019/04/30(火)12:53 ID:??? AAS
>>117
Oracleが発言してるんだからそれOracleに言って来いよ。
どうせOracleがActiveRecordを勘違いしてるんでしょ。
125: 2019/04/30(火)12:55 ID:??? AAS
>>120
言いたいことは大体分かったけど
なんかソースみたいな記事持ってこないと噛み付いてる人は納得しないと思うよ
126: 2019/04/30(火)12:56 ID:??? AAS
>>123
遅くなる問題があるからわざわざ専門チームがいて
賞金もかけられれるんでしょ。
PostgreSQLやMySQLの開発チームの中に
JOIN問題を解決する対策チームがいるからそいつらに言って
間違い正して来いよ。
127: 2019/04/30(火)12:57 ID:??? AAS
ARの定義知ってんの？
1レコード1エンティテイ
エンティテイがDBアクセスを担う
この二つを満たしてるものがActiveRecordたぞ。JPAは当てはまらない。Oracleが言ったからって信じるなよ。
上下前次1-新書関写板覧索設栞歴
あと 875 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.320s*