Laravelでテーブルのカラムの値のコード一覧はどこに書くべきか

Laravelを使っているシステムのソースコードを読んでいて疑問に思ったことがあります。
会員テーブル members があって、type というカラムがあります。type の値は「1は通常会員、2は特別会員」という意味です。
この「1は通常会員、2は特別会員」という値と名前の対応表（自分はコードリストと言っています）が、テーブルmembers のモデルクラス Member.php にこんな感じで書いてありました。

class Member extends Model
{
    public $typeTsujo = 1;
    public $typeTokubetsu = 2;

    public $typeCode = [
        1 => '通常会員',
        2 => '特別会員',
    ];

$typeTsujo と $typeTokubetsu は「通常会員の場合は…、特別会員の場合は…」のようなif文の条件でマジックナンバーを書かないようにするために使っています。$typeCode はbladeテンプレートで type を「通常会員」「特別会員」と出力したり、type を選択するラジオボタンを出すのに使っていて、またバリデーションルールでも使っています。
こういうコードリストってモデルクラスに書くのが普通なんでしょうか？「1は通常会員、2は特別会員」というのはテーブルの情報ではない（CREATE TABLE文にその情報はない）ので、自分としてはモデルクラスに書くのはなんか違う気がして。
仮にモデルクラスに書くにしても public なプロパティではなくて const でいいのではないかと思いました。publicプロパティだとただ $typeTsujo や $typeCode を参照するためだけにMemberクラスのインスタンスを作ったりしていて無駄ではないかと。
自分だったらtypeのマスタテーブル作るのは大げさな気がするし、config の下か resource/lang/ja の下にファイル作ってそこに書いたらいいんじゃないかと思ったのですが、どこに定義するのが適切なのでしょうか。

行動規範の内容に同意します

回答1件

大前提として、「チーム全体としてのルール」が既にあるのであれば、それに準拠するのが定石です（同じ「テーブル格納値を管理する値」なのに、config下にあったりmodel下にあったりするのはわかりにくいので）。

それはそれとして、「個人的にどう思うか？」「新規アプリだったらどうするか？」というお話であれば、私ならModelのconstに定義します。
※ただし、PHPのバージョンが古いとarrayはconstに定義できないので、提示されたサンプルコードのように、クラス変数に書くかもしれません。

「1は通常会員、2は特別会員」というのはテーブルの情報ではない（CREATE TABLE文にその情報はない）ので、自分としてはモデルクラスに書くのはなんか違う気がして。

仰るとおり、そのテーブルの情報ではないのですが、そのテーブルに格納されている値の情報です。
個人的には「テーブル関連情報は、そのテーブルのModelにまとめておくと便利かな」と思います。
もちろん、configの下に書くのも正しい対応だと思うのですが、デメリットもあるので、どちらを採用するかは検討の余地があると思います。

Modelに定義するメリット

・configに定義すると「テーブル数が増えてきた時に収集が付かなくなる（10テーブルに、定数定義すべきカラムが各3つあって、それぞれに5種類ずつ値があって……となると、それだけで150個の定数がconfigに並ぶことになります）。

・Modelの下に書いておくと、「この定数は、この用途でしか使っていない」というのがわかりやすい。

例：UserテーブルとItemテーブルの両方に「data_type」カラムというものがあったとして、定義値が全く異なる場合（※「そもそも、カラム名の付け方がイマイチ」という指摘はご容赦ください）

Userテーブルは 1:normal、2:special
Itemテーブルは 1:food、2:drink

configに「DATA_TYPE_NORMAL」「DATA_TYPE_SPECIAL」「DATA_TYPE_FOOD」「DATA_TYPE_DRINK」と定義されていると、どの定数がどのテーブルのdata_typeに入り得るのかがわかりません。

Modelクラスに定義してあれば、
$hoge = User::DATA_TYPE_NORMAL;

$fuga = Item::DATA_TYPE_FOOD;

と書くことができるので、Userテーブルのdata_typeには「DATA_TYPE_NORMAL」「DATA_TYPE_SPECIAL」しか入らないんだな、ということがわかります（間違えて User::DATA_TYPE_FOOD と書いても、未定義定数のためエラーになります）。

configで管理する場合でも「定数名のprefixとしてテーブル名を付ける」とすれば、この「混在問題」は回避できるのですが、あくまで「ルール」でしかないので、「あ、なんか似たような定数が定義されているから、これを使おう！」というケースが回避できない、というデメリットがあります。

投稿2018/12/17 04:11

nak

総合スコア696

intron

2018/12/23 11:24

回答ありがとうございます。 > ・configに定義すると「テーブル数が増えてきた時に収集が付かなくなる（10テーブルに、 > 定数定義すべきカラムが各3つあって、それぞれに5種類ずつ値があって……となると、 > それだけで150個の定数がconfigに並ぶことになります）。これはそんなデメリットでもないと自分としては思います。config配下の1ファイルに書いたとしても、命名規則をしっかり決めて分かりやすく書けばそんな混乱しないのでは。ただ、`users.type` の定数を編集するつもりで間違って `item.type` の定数を編集してしまうというミスは起こりうるとは思います。 > configで管理する場合でも「定数名のprefixとしてテーブル名を付ける」とすれば、 > この「混在問題」は回避できるのですが、 config に定義する場合はそうするつもりでした。異なるテーブルでカラム名が同じものはあるので。あとモデルクラスに定義するとその定数をbladeで使う場合、例えば「通常会員」と「特別会員」のラジオボタンを出力する場合に ``` @foreach (App\Models\Member::TYPE_CODES as $key => $value) <input type="radio" value="{{ $key }}">{{ $value }} @endforeach ``` のようにモデルクラス名を名前空間も含めて全部書くか、あるいは @php でインポートするかにで、いずれにしてもなんかイマイチな感じがします。config配下に定義してあれば config() でアクセスできて楽かなと。モデルクラスに定義した場合、config または resource 配下に定義した場合それぞれのメリット・デメリットをメンバーに説明して話し合いたいと思います。ありがとうございました。

行動規範の内容に同意します