用了 Repository 依赖来写业务逻辑，就不用 model 了？

Model 构建表之间关系

一直是 controller 中写逻辑，model 中处理表对应关系，没使用 repository

repository 是为了在 model 层前面加个数据处理层

• 业务写在写在 service 层
• 控制器做参数校验和任务的转发。
• 为什么要用 Repository
  service 调用 repository，service 不关心你的底层存储是 redis 还是 mysql 或者 monggodb 等等，这些东西统一由 repository 来处理好以后返回给 service。

  问题分析

  很多人说 repository 没有必要，针对个人小项目，因为本身也不会迭代出复杂的业务，所以分不分层都一样，所以他认为多了一层很麻烦。

  个人理解

  如果说代码不分层，认为其实控制器都没有存在的必要，直接在路由里面写就好了，多了控制器反而更麻烦。
  直接路由 -> 业务 -> 数据，这样更简单更快，但是实际工作场景产品的需求折磨的你死去活来，前期分层不明确就后导致代码一坨坨。

  建议你参考点灯坊的文章

这个不存在绝对。model 还是必要的啊。毕竟不建 model，怎么用模型操作数据库。model 上面加一层分工的更明确吧。

不用 Repository，laravel 的 ORM 足够了

好的，谢谢大家

我是 Model 只做关联定义和修改器访问器的定义，不做任何的查询插入等的处理逻辑

其实这个 Repository 怎么理解，如果是在 DDD 里面，它只是用于持久化数据，和业务没有太多关系，业务写在 model，此模型我更倾向于命名为领域模型，而不完全是一个 db 的映射，service 层来编排业务的执行和公开访问。