[表示 : 全て 最新50 1-99 2ch.scのread.cgiへ]
Update time : 07/23 09:28 / Filesize : 26 KB / Number-of Response : 88
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



38 名前:デフォルトの名無しさん mailto:sage [2021/09/18(土) 10:34:28.49 ID:FM0s+Kl2.net]
>>36
もちろん、フレームワークとしてそれらを使うことが強制されているわけではないよ。

EloquntやMigrationに限った話ではなく一般論として書くけど、
それぞれの方法のメリットとデメリットを正確に洗い出しせているか、洗い出した上でプロジェクトのチームとしてその選択をしたのならそれに従えば良い。

肝心なのはプロジェクトごとにルールが明確で全員がそれに従うこと。
ある人はEloquentのクエリビルダを使うが、ある人はSQLを直書きする。なんてことが無いように。

しかし、それらを使わない理由が「コードのメンテの際、マイグレーションやEroquentの理解が必要となるため」だけなら、理由としては弱いと思う。
ある別のメンバーがそれらを理解できずにコードの品質が落ちる、という理屈が通るなら、
「○○の機能を使うと、新しいメンバーが参加する障壁となるから、もっと原始的な仕組みにしよう。原始的な△△なら誰でも理解している」は全てに言えてキリがなくなってしまわないだろうか。

例えば、
・Eloquentは理解に時間がかかるから使用NG
・Migrationも同じく駄目
・FormRequestも使わずにコントローラーにバリデーションのコードを書けば誰もが理解できる
・Moddlewareも使わずに全てのコントローラーの開始と終わりに必要なコードを書けばその処理に気づかない人はいないはず
・Helperも使わずに都度phpの標準関数を組み合わせて書けばいちいちLaravelのヘルパを知る必要は無い
・Observerは使わずにレコードの書き換えを行う全てのメソッドで必要な処理を書くべき
・36の言う「DBの管理アプリは良い」は○○だから使うべき
それらの基準を明確してからルールを決めて、それが適切なのかを他のメンバーから客観的な評価をもらうべき。






[ 続きを読む ] / [ 携帯版 ]

全部読む 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](*・∀・)<26KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef