关于数据库中一些数字字段定义的思考

单独开一个Constants类

PS:我感觉换Model的情况的可能性几乎为0……

我一般都写到Model里面，不过确实看起来不够优雅，是否可以对应写一个类中，类中只定义常量，比如User 中只定义User相关的const，mark一下，坐等其他评论

@leo 多谢，你帮了我很多次了，十分感谢，Model确实很少换，但我确实遇到过，在Repository注入不同的Model，情况很少，

写 Model 里面

本来就是模型相关，当然写模型里

同样的问题

因为绑定了接口和实现，各地其实是在直接用接口，所以我们写在接口里面了

不知道有没有更好的办法，repository 确实是带来了各种不方便的地方。

  3 namespace App\Repositories\Contracts;
  4
  5 interface FooRepository
  6 {
  7     const STATUS_PROCESSING = 1;
  8     const STATUS_SUCCESSED = 2;
 12 }

分享一下我这边的开发方式。

说实话， Repository 用起来还是很繁琐的，并且新人学习 laravel 成本本来都高。我这边使用了这样的方式，

例如下面是一个用户模型：

class User extends BaseModel implements AuthenticatableContract, AuthorizableContract, CanResetPasswordContract
{

    use Authenticatable, Authorizable, CanResetPassword;
// 关联关系
    use UserRelationship;
// 和 User 相关的数据仓库
    use UserRepository;
// 用户角色和权限
    use UserAccessRepository;
// Set 和 Get
    use UserAttribute;
// 搜索专供
    use UserScope;
// 权限（通用的，其他模型也可能需要的）
    use PermissibleTrait;

    use SoftDeletes;
    use LogAbleTrait;

    const GENDER_FEMALE = '女';
    const GENDER_MALE = '男';

    const STATUS_VAILD = '正常';
    const STATUS_TURNOVER = '离职';
    const STATUS_LOCK = '锁定';
    const STATUS_UNVERIFY = '待审核';
    const STATUS_INVAILD = '失效';

    protected $fillable = [
        'address',
        // 很多其他的字段，不列出来了
    ];

    protected $casts = [
        'approval_status' => 'boolean',
        'scores_info'     => 'json',
    ];

    protected $dates = [
        'approved_at',
        'deleted_at',
        'worked_at',
        'birthday',
    ];

    protected $hidden = [
        'password',
        'permissions',
        'remember_token',
    ];

    protected $appends = [];

    protected $loads = [
        'company',
        // 还有其他的关联
    ];

    protected $indexs = [
        '*'
    ];
}

目录的结构如下

可以看到，模型文件里面主要都是配置类信息，所有的业务逻辑、搜索、更改器、关联等等都拆分到了 trait ，这样保证每个文件不会过于长，过于复杂，提高了可读性，并且新手也可以使用。这里的 Repository 我称之为 小数据仓库，至于你们说的那种可以换 model 的 大仓库 我觉得真实情况下很少用到。如果真的需要了，再改，也不难 :smile: 。

这样的话，带新人很容易，看懂官方文档，项目里面代码写到合适的地方。间接的实现了代码的分离（其实还是在一起），和一定的可读性。

不要过度设计 -- Jobs

@liyu001989 很感谢你的回答，我现在直接开辟了另一个类来解决这个问题，同时也解决了算是部分冗余的问题，因为比如status这个字段，很多表会用到，并且状态差不多，那么我就这一个类搞定

@zhuzhichao ，非常感谢，我之前是用Repository并且还指了RepositoryInterface，但实现过程中确实发现非常繁琐，现在在重构考虑到Repository可能需要注入不同的模型，但自己本身被改变的机率却非常小。

已经去除了RepositoryInterface，直接使用Repository，发现轻松好多。我使用的是自己造的仓库轮子，也参考了Github上的一些代码，用起来感觉还行 https://github.com/crcms/repository